This PR adds the __class_getitem__ classmethod to the ndarray, dtype and number classes,
mimicking what PEP 585 did for the standard library. Consequently, expressions that were previously
only allowed in .pyi stub files or with the help of from __future__ import annotations are now also
legal during runtime.

A couple things of note (most of them summarized from the linked PEP):

• The new __class_getitem__ method returns parametrized wrapper (types.GenericAlias) around the original type and, in most situations, can be used whenever the non-wrapped type is expected.
• The types.GenericAlias class is only available for for python >= 3.9, consequently __class_getitem__ will only be available for these version.
• types.GenericAlias performs no minimal validation (i.e. checking the number of passed parameters) on the passed object, so this means that __class_getitem__ can in practice take any object. I'm personally not a huge fan of this, but, on the other hand, I feel that copying the stdlib approach here is the lesser of evils due to its simplicity and maintainability, especially since the more thorough argument parsing performed by typing.Generic.__class_getitem__ is quite complex and prone to change.
• Matching the stub files, the concrete number subclasses (uint8, int32, etc.) are treated as if they were already subscribed, and will thus raise upon calling __class_getitem__ due to a lack of free parameters.

Examples

In [1]: import numpy as np
   ...: from typing import Any

In [2]: np.dtype[np.int64]
Out[2]: numpy.dtype[numpy.int64]

In [3]: np.inexact[Any]
Out[3]: numpy.inexact[typing.Any]

In [4]: np.ndarray[Any, np.dtype[np.float64]]
Out[4]: numpy.ndarray[typing.Any, numpy.dtype[numpy.float64]]

In [5]: np.float64[Any]
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-d62322c38e84> in <module>
----> 1 np.float64[Any]

TypeError: There are no type variables left in numpy.float64