Feature request: an additional config context for forcing conversion toward a specific Array API-compatible array library.

### Describe the workflow you want to enable

Per https://github.com/scikit-learn/scikit-learn/pull/22554 such workflow is possible:

```python
from sklearn.datasets import make_classification
from sklearn import config_context
from sklearn.discriminant_analysis import LinearDiscriminantAnalysis
import cupy.array_api as xp

X_np, y_np = make_classification(random_state=0)
X_cu = xp.asarray(X_np)
y_cu = xp.asarray(y_np)
X_cu.device


with config_context(array_api_dispatch=True):
    lda = LinearDiscriminantAnalysis()
    X_trans = lda.fit_transform(X_cu, y_cu)
```

(see https://scikit-learn.org/dev/modules/array_api.html )

I would like to additonally enable following workflow:

```python
X_np, y_np = make_classification(random_state=0)

with config_context(array_api_dispatch=True, array_api_namespace=xp):
    lda = LinearDiscriminantAnalysis()
    X_trans = lda.fit_transform(X_np, y_np)
```

where `X_trans` are the same in both examples, and in both examples compute has been done with `cupy`.  The difference is that we pass numpy inputs and rely on the estimator to convert using the appropriate array namespace.

The added value here for the user is that the `check_array` function could be used to load arbitrary inputs to the array library relying on its `xp.asarray` method, in a way that is consistent to `sklearn.utils.validation.check_array` requirements accross all array libraries.

Currently, a user that would have data formated as, let's say, a list of lists, has two choices:

- either pass the list of list directly to `lda.fit`, but then since the list of list does not have a `__array_namespace__` attribute it will fallback to numpy array namespace
- either convert first the input to `cupy`, but then, unless the user re-implements methodically `check_array` with `cupy` conversion, the behavior of the conversion might differ from what `check_array` would do when converting to `numpy`, and anyway reimplementing `check_array` is not very efficient to begin with.

**Edit:** following discussions, adding examples that highlights the added value I can see to memory management with such an interface:

```python
X_np, y_np = my_data_loader()  # let's assume that X_np, y_np are typed `np.int64`...

# as a consequence, here the cupy array are also typed `int64`
X_cu = xp.asarray(X_np)
y_cu = xp.asarray(y_np)
X_cu.device

with config_context(array_api_dispatch=True):
    lda = LinearDiscriminantAnalysis()
    # But `lda` requires `floats` to work
    # (see https://github.com/scikit-learn/scikit-learn/blob/f3f51f9b6/sklearn/discriminant_analysis.py#L551)
    # so implicitly, an additional copy of X_cu and y_cu in `float` is going to be created
    # resulting on twice the memory allocation for data.
    X_trans = lda.fit_transform(X_cu, y_cu)
```

for the unwary user, this workflow is safer:

```python
X_np, y_np = my_data_loader()  # let's assume that X_np, y_np are typed `np.int64`...

with config_context(array_api_dispatch=True, array_api_namespace=xp):
    lda = LinearDiscriminantAnalysis()
    # The X_np, y_np are yet again implicitly transformed as cupy float arrays. But
    # the intermediate copy that the users created is skipped (or at worst,
    # deleted right after creation), resulting in better memory management.
    X_trans = lda.fit_transform(X_np, y_np)
``` 

### Describe your proposed solution

The `get_namespace` function can query the `config_context` and force the use of the `__array_namespace__` that is set by the config rather than the `__array_namespace__` that attached to the input (if any). (rather simple solution)

COMMENT:
> this point about memory efficiency? If memory efficient is the goal, then I think this feature request makes a more sense. Functionally, the Array API specification does not support `order`, so we would only get efficiency gains from `dtype`.

I wish that could change, the current default of ignoring `order` in the early work on array api is confusing, shouldn't an error be raised in this case ? I've been working recently with another library [dpctl.tensor](https://intelpython.github.io/dpctl/latest/docfiles/dpctl/dpctl.tensor_pyapi.html) that implements the Array API and the `asarray` method [does also expose](https://intelpython.github.io/dpctl/latest/docfiles/dpctl/dpctl.tensor_functions_api.html#dpctl.tensor.asarray) the `order` argument but it will not be used because of this. What would you think of inspecting the signature of `xp.asarray` and pass the `order` argument if `xp.asarray` implemennts it ?

Edit: despite https://github.com/scikit-learn/scikit-learn/pull/22554#discussion_r826984224 I think in sklearn there is expanded use of `order` ? implementation with low level languages will usually perform better with a layout (example [kmeans](https://github.com/scikit-learn/scikit-learn/blob/f3f51f9b6/sklearn/cluster/_kmeans.py#L1371)) . Is there still an ongoing discussion with the Array API or is it closed at the moment ? If closed, we might also consider exposing `get_namespace` / `_asarray_with_order` to [plugins,](https://github.com/scikit-learn/scikit-learn/issues/22438).

Labels: New Feature, Needs Decision - Include Feature, Array API