…testing so very much a WIP still.

…and only use json on numpy arrays for now.

…ires python 3.7.1+, but apparently pinning python to `^3.7` which is supposed to be equivalent to `>=3.7, <4.0` doesn't let the stack resolve, so pinning python to `^3.7.1` was the correct solution, even though it should have resolved...

…ther. I moved the commented block in case we needed to change it later.

…te, so split it up the hard way since there doesn't appear to be any other way to acess the name.

This is the single most frustrating bug to track down since the error is thrown in pydantic but doesn't backtrace through the pydantic.__getattr__ -> `AutoPydanticDocGenerator` -> `__get__` -> `doc_formatter` -> `annotation.__name__` function because all the exceptions are caught the whole way up. GYA!

…ping and pre Python3.9 in tandem with typing_extensions Annotation

Source information: beartype/beartype#42

Annotated checks against instances of _GenericAlias to see if you can support Data[type_info], e.g. NDArray[int] (in Python types since 3.9, and kinda of as _GenricAlias before that.) Prior to 3.9, Numpy implemented their own version of _GenericAlias which isn't Python _GenericAlias, so the types are not considered "Generic" when Annotated[NDArray, Metadata][type_info] does its thing. So. This fix code does the heavy lifting to re-cast the NDArray type with _GenericAlias from python typing. I've tried to reuse as much data from NDArray as I possibly can and still use np.ndarray (which is not np.typing.NDArray) to still correctly type hint np.ndarrays.

…lization wrappers together. Who knew? Also fixed an issue where the default `model_dump` wasn't calling the correct settings.

…d as a function first before calling tolist

…ich calls different logic overall than to_jsonable_python for some reason I don't understand