optypean dtype-like type-aliases

[jorenham]

This effectively comes down to porting over the optype.numpy.Any*DType type aliases (docs), and stripping away the compatibility stuff for older numpy version.

naming scheme

The naming scheme of these dtype-likes in optype.numpy is admittedly rather awkward, so a that should also be changed (but not in optype; that'd break scipy-stubs).
Some options for a new naming scheme are (taking dtype[int8] and dtype[str_] as example)

• As{}DType (pros: np.dtypes compat, cons: no abbrev & meh readability)
  • AsInt8DType
  • AsStrDType
• AsDType{} (pros: autocompletion & could abbr, cons: yoda & np.dtypes incompat)
  • AsDTypeInt8 / AsDType_int8 / AsDType_i1
  • AsDTypeStr / AsDType_str / AsDType_U
• DTypeLike{} (pros: autocompletion & could abbr & np._typing compat, cons: long & yoda & np.dtypes incompat)
  • DTypeLikeInt8 / DTypeLike_int8 / DTypeLike_i1
  • DTypeLikeStr / DTypeLike_str / DTypeLike_U
• {}DTypeLike (pros: readability & np.dtypes compat, cons: long & no abbrev)
  • Int8DTypeLike
  • StrDTypeLike

datetime64 and timedelta64

Analogous to the three or four distinct generic variants of the scalar types (unit-based), these dtypes could be further split up into "sub-dtype-likes" for:

• datetime64[None] / datetime64[int] / datetime64[dt.datetime] / datetime64[dt.date]
• timedelta64[None] / timedelta64[int] / timedelta64[dt.timedelta]

void

Note that for void things become rather complex, because it includes all possible structured dtypes, but can also be bytes-like. So perhaps it makes sense to split it up into two non-overlapping dtype-like types:

• structured, i.e. those with .ndim > 0: accepts list[tuple[...]] | ct.Struct | ct.Enum
• raw, i.e. those with .ndim == 0: accepts type[void] | L["void", "V", "\x14", ...] | ...

incompleteness

Not all dtypes can be completely described, because they accept an infinite amount of possible strings. This is the case for

• datetime64 and timedelta64 (i.e.e.g. "M8[42as]")
• flexible, i.e. bytes_, str_, and void (i.e.e.g. "S1337")

So in these cases, a "catch-all" overload for the remaining str should be used.