Make `zero_division` parameter consistent in the different metric

This is an issue to report the step to actually take over the work of @marctorsoc in https://github.com/scikit-learn/scikit-learn/pull/23183 and split the PR into smaller one to facilitate the review process.

The intend is to make the `zero_division` parameter consistent across different metrics in scikit-learn. In this regards, we have the following TODO list:

- [x] Introduce the `zero_division` parameter to the `accuracy_score` function when `y_true` and `y_pred` are empty.
    - https://github.com/scikit-learn/scikit-learn/pull/29213
- [x] Introduce the `zero_division` parameter to the `class_likelihood_ratios` and remove `raise_warning`.
    - https://github.com/scikit-learn/scikit-learn/pull/31331
- [x] Introduce the `zero_division` parameter to the `cohen_kappa_score` function
  - https://github.com/scikit-learn/scikit-learn/pull/29210
- [x] Introduce the `zero_division` parameter to the `matthew_corr_coeff` function
  - #23183
  - #28509
- [ ] <del>Open a PR to make sure the empty input lead to `np.nan` in `classification_report` function.</del> `classification_report` should raise an error instead: see https://github.com/scikit-learn/scikit-learn/issues/29048#issuecomment-2857931743

All those items have been addressed in #23183 and can be extracted in individual PRs. The changelog presenting the changes should acknowledge @marctorsoc.

In addition, we should investigate #27047 and check if we should add the `zero_division` parameter to the `precision_recall_curve` and `roc_curve` as well. This might add two additional items to the list above.

COMMENT:
I can see part of the problem, but another part seems too far.

> The second group are functions where there are multiple places in the computation where a zero division can happen
...
> - Ignoring them might not be a desired action, and might be misleading, but sometimes users might want it 
> - score(..., zero_division=np.nan) wouldn't be returning np.nan, and it would simply be ignoring those nan values in mean calculation, which isn't intuitive by looking at the user code

Yes, both of them speaks for having an additional "ignore" option for this second group.
But comment: sometimes we might not want to ignore, but to neutralise (this was decided to do when introducing nan support in SplineTransformer, even though I'm aware this is not a metric).

> - There is no way for the user to get a np.nan when there's a division by zero, which is the case for metrics in the first group.

Isn't there the default behaviour of warning/erroring, which we keep from before? Raising an warning/error is basically as good as returning a single `np.nan` for a score that aggregates. Users can catch it and precede as they need. Not so much of a problem, I think. We could of cause offer the option to return np.nan instead of warning, but it doesn't seem to add much value.

> - There are no warnings raised in the case of user passing `zero_division=np.nan` and this might not be ideal.

Why not? Users can chose between default `"warn"` and `np.nan` and it's documented that only the first option raises a warning.

> - The control of whether or not a warning is raised and what to replace the value with, are both in a single argument, but they're different things.

The only option to get around such things is to use two different params to control this, but we can also define a collection of things to happen when setting just one param, if we have curated them well. I think we are doing this all over the project.

> Introduce a `replace_undefined_by` argument, deprecating `zero_division` away. 

Do we have other reasons in our code for a scoring function to be undefined at certain values? Otherwise we could maybe keep the old param name and only add an `"ignore"` option for functions that aggregate several values into one?

Labels: Enhancement