Floats besides float64 were being coerced to integers in np.mgrid and complex step sizes for the index trick classes would fail for complex64 input. Fixes #16466

Before:

>>> np.mgrid[np.float32(0.1):np.float32(0.33):np.float32(0.1),]
array([[0, 0, 0]])
>>> np.r_[0:10:np.complex64(3j)]
array([], dtype=complex128)

After:

>>> np.mgrid[np.float32(0.1):np.float32(0.33):np.float32(0.1),]
array([[0.1, 0.2, 0.3]])
>>> np.r_[0:10:np.complex64(3j)]
array([ 0.,  5., 10.])

The input types do not affect the output dtype, which are always int64 or float64, but they can affect the output in other ways due to arange precision issues (#5808).

>>> np.mgrid[np.float32(0.1):np.float32(0.3):np.float32(0.1)]
array([0.1, 0.2, 0.3])
>>> np.mgrid[np.float64(0.1):np.float64(0.3):np.float64(0.1)]
array([0.1, 0.2])

@seberg mentioned that the mgrid code could use a refactor. A lot of its functionality is duplicated in AxisConcatenator and meshgrid. I think the code could almost be replaced by np.meshgrid(*[np.r_[k.start:k.stop:k.step] for k in key], sparse=self.sparse). I could verify this and clean it up if it sounds reasonable.