`type_of_target` returns `unknown` for valid arrays of dtype `object`

### Describe the bug

`sklearn.utils.multiclass.type_of_target` returns unknown for arrays of integers if they have a dtype of `object`, when it should instead return a valid type.

I would be happy to contribute a fix, but I'm not entirely sure how the failing condition should be corrected:
https://github.com/scikit-learn/scikit-learn/blob/45756377c748d84aa52f66950b8d9eeefc31456c/sklearn/utils/multiclass.py#L317-L319

### Steps/Code to Reproduce

```python
import pandas as pd
from sklearn.utils.multiclass import type_of_target

series = pd.Series(['a', 'b'])
series.loc[series == 'a'] = 0
series.loc[series == 'b'] = 1

print(series)
print(type_of_target(series))
print(type_of_target(list(series)))
```
Output is `unknown` whereas once converted to a list, the output is `binary` as expected.

### Expected Results

`type_of_target` returns a valid type (`binary`).

### Actual Results

This issue resulted in enigmatic errors when using dependent functions such as `confusion_matrix`, e.g.:
```
Traceback (most recent call last):
  File "test.py", line 214, in <module>
    cm = confusion_matrix(y_test, prediction_classes)
  File "~/.pyenv/versions/wat/lib/python3.8/site-packages/sklearn/metrics/_classification.py", line 307, in confusion_matrix
    y_type, y_true, y_pred = _check_targets(y_true, y_pred)
  File "~/.pyenv/versions/wat/lib/python3.8/site-packages/sklearn/metrics/_classification.py", line 93, in _check_targets
    raise ValueError(
ValueError: Classification metrics can't handle a mix of unknown and binary targets
```

### Versions

```shell
System:
    python: 3.8.0 (default, Oct  6 2020, 12:20:13)  [GCC 6.5.0 20181026]
executable: ~/.pyenv/versions/wat/bin/python3
   machine: Linux-4.15.0-132-generic-x86_64-with-glibc2.27

Python dependencies:
      sklearn: 1.1.2
          pip: 22.0.4
   setuptools: 58.1.0
        numpy: 1.23.2
        scipy: 1.6.0
       Cython: 0.29.21
       pandas: 1.1.3
   matplotlib: 3.3.3
       joblib: 1.0.0
threadpoolctl: 2.1.0

Built with OpenMP: True
Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 237, in 'calling callback function'
  File "~/.pyenv/versions/wat/lib/python3.8/site-packages/threadpoolctl.py", line 400, in match_module_callback
    self._make_module_from_path(filepath)
  File "~/.pyenv/versions/wat/lib/python3.8/site-packages/threadpoolctl.py", line 515, in _make_module_from_path
    module = module_class(filepath, prefix, user_api, internal_api)
  File "~/.pyenv/versions/wat/lib/python3.8/site-packages/threadpoolctl.py", line 606, in __init__
    self.version = self.get_version()
  File "~/.pyenv/versions/wat/lib/python3.8/site-packages/threadpoolctl.py", line 646, in get_version
    config = get_config().split()
AttributeError: 'NoneType' object has no attribute 'split'

threadpoolctl info:
       filepath: ~/.pyenv/versions/3.8.0/envs/wat/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 8

       filepath: ~/.pyenv/versions/3.8.0/envs/wat/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-085ca80a.3.9.so
         prefix: libopenblas
       user_api: blas
   internal_api: openblas
        version: 0.3.9
    num_threads: 8
threading_layer: pthreads
```

COMMENT:
> This is quite a twisted use case. series was created to be an object array used for strings. However, you are reassigning manually integers within this object container. Therefore, instead of having an integer NumPy array (would we be fine), you have an object series containing some integer.

Hmm, perhaps. I understand it's not the greatest way of doing things, but this wasn't my code - I used the following example (https://github.com/serengil/tensorflow-101/blob/master/python/Ensemble-Face-Recognition.ipynb), where the initial `decision` (target) values ("No", "Yes") are changed to (`0`, `1`) for training, definitely a conceivable use-case.

> I assume that in this case, we could try to specify better the error message by checking which types are in the object array sequence.

Even that would definitely be very helpful!

Labels: Enhancement, module:utils