`MinMaxScaler.fit_transform()` overflow when input array is `float16`

### Describe the bug

I often use `float16` array to save working memory, but when I use `MinMaxScaler.fit_transform()`, some values overflow and become `inf`.
This occurs even if the transfomed values can fit to the range of float16.

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.preprocessing import MinMaxScaler


array = np.arange(11, dtype='float16').reshape((-1, 1))

scaler = MinMaxScaler(
    feature_range=[-60000, 60000],
    copy=True,
    clip=False
)
scaled_array = scaler.fit_transform(array)
print(scaled_array)
```


### Expected Results

```console
array([[-60000.],
       [-48000.],
       [-36000.],
       [-24000.],
       [-12000.],
       [     0.],
       [ 12000.],
       [ 24000.],
       [ 36000.],
       [ 48000.],
       [ 60000.]], dtype=float16)
```


### Actual Results
With warnings `/home/takahisa/miniconda3/envs/sklearn_latest/lib/python3.8/site-packages/sklearn/preprocessing/_data.py:507: RuntimeWarning: overflow encountered in multiply
  X *= self.scale_`,
```console
array([[-60000.],
       [-48000.],
       [-36000.],
       [-24000.],
       [-12000.],
       [     0.],
       [    inf],
       [    inf],
       [    inf],
       [    inf],
       [    inf]], dtype=float16)
```

Additionally, this might be a separate issue, but if I change the dtype of input `array` in the above code, only when input array dtype is `float32`, output array is `float32`. 
This seems inconsistent, but is it intended?

### Versions

```shell
System:
    python: 3.8.3 | packaged by conda-forge | (default, Jun  1 2020, 17:43:00)  [GCC 7.5.0]
executable: /home/takahisa/miniconda3/envs/sklearn_latest/bin/python3.8
   machine: Linux-5.15.0-47-generic-x86_64-with-glibc2.10

Python dependencies:
      sklearn: 1.1.2
          pip: 22.2.2
   setuptools: 65.3.0
        numpy: 1.23.3
        scipy: 1.9.1
       Cython: None
       pandas: None
   matplotlib: None
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/takahisa/miniconda3/envs/sklearn_latest/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: Zen
    num_threads: 12

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /home/takahisa/miniconda3/envs/sklearn_latest/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/takahisa/miniconda3/envs/sklearn_latest/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Zen
    num_threads: 12
```

COMMENT:
thanks @amano-takahisa, I can reproduce. The overflow comes from the fact that some intermediate computations do overflow because we scale X and then translate, so the first scaling ends up out of range.

However I'm not sure we can always guarantee that intermediate computations won't overflow. If we first translate and then scale for instance we can trigger an overflow as well with a different array.

Labels: Bug, Needs Triage