RFC SLEP006: allow users to enable a "strict" mode in metadata routing

ref: https://github.com/scikit-learn/scikit-learn/pull/22986/files#r862344847

Along the way we've had discussions on whether we should raise if a metadata is requested but not provided.

Mirroring the existing behavior, SLEP006 and the implementation won't raise in the following case:

``` python
pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=True)).fit(X, y)
```

Should we allow a strict mode, either globally or on the estimator level, which would make the above code raise?

COMMENT:
> For me, I prefer the final API to raise an error. In your example, `LogisticRegression` is configured to have a `sample_weight`, but is it not provided one. If we do nothing, then the following two pipelines have the same behavior:
> 
> ```python
> pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=True)).fit(X, y)
> 
> pipeline = make_pipeline(LogisticRegression()).fit(X, y)
> ```
> 
> That feels weird to me.
> 
> Do you think the final API should be strict by default?

I agree with this example being weird, and to make the example even more poignant, the below two are identical.

```python
pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=True)).fit(X, y)

pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=False)).fit(X, y)
```

I personally would prefer some explicit parameter that will raise. To illustrate an example, suppose someone investigating the hypothesis of: "does `sample_weight` help my estimator?"

Research code is often hasty and you might expect that setting `sample_weight=True` means that it will use the `sample_weight` and `sample_weight=False` does not. Then in the process of writing the evaluation code, a mistake was made and the `sample_weight` was never passed in.
At the end I look at my numbers and conclude it does not help my estimator.

Of course this is an example of user error, but sklearn is very good at validating correctness and the expectations for this new feature would be no different. From experience, experimentation code in machine learning research is riddled with these subtle bugs and sklearn is great at informing users about them.

As for the exact semantics of specifying `"strict"` or `True` or some enum value, I don't think it matters too much.

---

One API recommendation to limit new methods or new parameters to simply introduce a new value type that determines behaviour, namely `.set_fit_request(sample_weight="strict")` or `.set_fit_request(sample_weight="required")`. I don't think this would conflict with anything but there might be code that already exists that does something like:

```python
if param["sample_weight"]:  # Relies on implicit "truthyness"
   # do...
```

The above proposal would not work in this case as `bool("strict") == True`.
This can be fixed internally in sklearn but depending on the current adoption of metarouting, this could introduce a silent bug in existing code.

EDIT: The above API with "strict" proposal would technically conflict with semantics defined in [1.1.4. Advanced: Different scoring and fitting weights](https://scikit-learn.org/stable/metadata_routing.html#advanced-different-scoring-and-fitting-weights). It would be odd for someone to use it but it means that simply checking for a `str` would not work internally. I don't have any other ideas that weren't mentioned in that case.

Labels: API, RFC