Embed the dtype-like types in the scalar types

Similar to the NEP 50 embeddings that are powering the _numtype.CastsWith* type alias, it should be possible to create an dynamically specializing dtype-like alias. This unifies all 24 individual _numtype.ToDType* as a single generic type, without loss of specificity.

The idea is to define a type-check only method in each scalar-type, e.g in int8:

@type_check_only
def __dtype_like__(self, like: int8, /) -> tuple[
    type[int8 | ct.c_int8] | HasDType[int8] | L["int8", "i1", ...],
    Self,
]: ...

The return-types of must not overlap, and overloads cannot be used, and don't annotate like with Self.

In _numtype:

@type_check_only
class CanDTypeLike[
    +DTypeLikeT,
    +OutT: np.generic,
    -LikeT: np.generic = np.generic,
](Protocol):
    def __dtype_like__(self, like: LikeT, /) -> tuple[DTypeLikeT, OutT]: ...

And I'm hoping it can be used like this

def scalar[
    DTypeLikeT, 
    OutT: (bool_, int8, uint8, int16, ...),
    LikeT: np.generic = np.generic,
](
    dtype: _DTypeLikeT,
    *,
    like: LikeT | None = None
    __out: CanDTypeLike[DTypeLikeT, OutT, LikeT] = ...,  # type-check only
) -> OutT: ...

The LikeT is optional, but can be used to dynamically constrain OutT. It can also be provided manually, which is less verbose than having to re-define the entire "typevar with constraints".

It's not certain whether this will work in practice, as it requires pretty powerful constraint solving. I guess there's only one way to find out 🤷🏻

Start by reviewing the scalar-type stubs and the _numtype definitions, especially the existing _numtype.ToDType* aliases and CastsWith* aliases. Check whether the proposed __dtype_like__ and CanDTypeLike signatures can be resolved by the supported type checker. Done means the individual aliases are unified without losing specificity and the affected scalar typing behavior is validated.