Fix type checking errors when using built-in types as dtype

[MilanStaffehl]

Bug fix for #6:

Sometimes, type checkers will complain about certain dypes, since they are not actually typed as subtypes of np.generic in numpy. Example:

import numpy as np

def stringify_dtype(dtype: np.generic) -> str:
    return dtype.__name__

stringify_dtype(np.float64)  # <--- causes error on x64 architectures

The above example, run against mypy on a 64-bit architecture, results in the following error:

Argument 1 to "stringify_dtype" has incompatible type "type[floating[Any]]"; expected "generic"  [arg-type]

A very similar issue occurs when using builtins, which are technically allowed as ndarray dtypes, but will also cause an error:

import numpy as np
from numdantic import NDArray, Shape

x: NDArray[Shape[int, int], float]  # <--- causes an error in type checkers

The error is similar:

Type argument "float" of "NDArray" must be a subtype of "generic"  [type-var]
Incompatible types in assignment (expression has type "ndarray[Any, dtype[signedinteger[_32Bit]]]", variable has type "ndarray[tuple[int, int], dtype[float]]")  [assignment]

Potentially one could get around the problem by writing a custom type that includes type[floating[Any]] etc. plus built-ins and then just ignore the fact that np.ndarray is typed in a way that will not allow this type (since it only accepts np.generic as dtype - which these apparently aren't).

[MilanStaffehl]

Regarding the built-in types: https://github.com/numpy/numpy/issues/23663

np.float_ is a subtype of float, so there is a relation, it's just "upside-down" with numpy generics being subtypes of the built-in, not the other way around.

[MilanStaffehl]

Seeing as how #6 was seemingly a sleep-deprived mistake on my end, this issue is now mostly related to using built-in types in NDArray types. Will update title accordingly, and will later update the description as well.

See comment in #6.