Describe `set_{method}_request()` API, expose `_MetadataRequester`, or expose `_BaseScorer`

### Describe the issue linked to the documentation

TL;DR: Metadata routing for scoring could either use a base class or documentation of how to write `set_score_request()`.

Currently the [Metadata Estimator Dev Guide](https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_metadata_routing.html#metadata-routing) has examples of a metadata-consuming estimator and a metadata-routing estimator.  However, the metadata routing is also designed for scorers and CV splitters which may or may not be estimators.   Fortunately, `sklearn.model_selection` exposes `BaseCrossValidator`, which like `BaseEstimator`, subclasses `_MetadataRequester`.  Unfortunately, ~there's no base class for scorers.~ the base class for scorers, `_BaseScorer`, is not public.

I don't understand how to string together the relevant methods that should be a part of `set_score_params`, The current workaround is to simply subclass `BaseEstimator`, even if I'm not making an estimator, or to subclass `_MetadataRequester`, even though its not part of the public API.  ~Or use `make_scorer` to pin the kwargs when instantiating the meta-estimator, rather than in `fit()`~

My use case is for scoring a time-series model where the data generating mechanism is known to the experiment, but not the model, and I need to compare the fit model to the true data generating mechanism.  I understand how to use a custom scorer in `RandomizedSearchCV`, and the [metadata API](https://scikit-learn.org/stable/metadata_routing.html#api-interface) explains how meta estimators like `RandomizedSearchCV` can pass additional arguments to my custom scorer.

### Suggest a potential alternative/fix

* publicly exposing `_MetadataRequester`
* publicly exposing `_BaseScorer`
* Document how to write the `set_{method}_request()` methods.  It looks like `_MetadataRequester` uses a descriptor `RequestMethod`, which relies on an instance having a `_get_metadata_request` method and a `_metadata_request` attribute (which it doesn't really describe).

EDIT: Found out about `_BaseScorer`.  Also, removed `make_scorer` workaround, as it doesn't result in passing the fitted estimator to the `_score_func`

COMMENT:
> suggested actions read (to me) like a list of alternatives - so the first step here is to have a discussion about the options and form a consensus

Exactly - I know metadata routing is newish and evolving, and I'm interested in what other considerations and plans y'all have.  I'd be hesitant to suggest anything without that knowledge.

> While make_scorer is convenient for simple functions, creating more complex, stateful scorers that properly handle metadata routing by inheriting from an internal class is not a viable public pattern.

I don't know that it's inviable; after all, it is possible to just subclass `_BaseScorer` and override `__call__()`.  I think a base class discussion revolves around what housekeeping chores [`_BaseScorer.__call__()`](https://github.com/scikit-learn/scikit-learn/blob/ce4a40ffae5005ffa30f87b198b176dc6eb0f160/sklearn/metrics/_scorer.py#L264) and [`_Scorer._score()`](https://github.com/scikit-learn/scikit-learn/blob/ce4a40ffae5005ffa30f87b198b176dc6eb0f160/sklearn/metrics/_scorer.py#L360) do that may be important to have in custom scorers.
### `_BaseScorer.__call__()`
* initializes with `score_func, sign`
* Checks whether metadata was routed with metadata routing disabled and raises an error

### `_Scorer._score()`
* tells a cacheing `method_caller` what kinds of predictions/transforms an estimator makes 
* checks whether kwargs were both passed directly and via metadata
* calls `self._score_func(y_true, y_pred, **scoring_kwargs)`

I mentally sort these capabilities into (a) dynamic machinery to determine what methods an estimator has, how to call methods, and how to handle metadata vs (b) mechanics of scoring that a user can fiddle with.  The thing that makes it hard to determine what public class comes out of this is that there isn't a clear sorting of (a) and (b) into different methods.  OTOH, on the question of exposing `_MetadataRequester`:

> "`_MetadataRequester`'s functionality is best exposed through classes that inherit it... , rather than exposing it directly for all users, as it's more of a mixin/building block"

I think mixins are fine; after all, scikit-learn has `TransformerMixin`.   I think the distinction that matters is the difference between [`_BaseScorer.set_score_request()`](https://github.com/scikit-learn/scikit-learn/blob/ce4a40ffae5005ffa30f87b198b176dc6eb0f160/sklearn/metrics/_scorer.py#L323)  and the default `set_{method}_request()` descriptors in [`_MetadataRequester.__init__subclass()`](https://github.com/scikit-learn/scikit-learn/blob/ce4a40ffae5005ffa30f87b198b176dc6eb0f160/sklearn/utils/_metadata_requests.py#L1396).  I don't know enough to understand how they differ.

Labels: Documentation, Needs Investigation, Metadata Routing