Inconsistency in zero_division handling between precision/recall/f1 and precision_recall_curve/roc_curve related metrics

### Describe the workflow you want to enable

The API offers the possibility to set the behavior upon stumbling upon a zero division issue when no positive label is present in the dataset, upon computing `precision_score`, `recall_score` or `f1_score` using the keyword argument:

    zero_division{“warn”, 0.0, 1.0, np.nan}, default=”warn”

    Sets the value to return when there is a zero division.

    Notes: - If set to “warn”, this acts like 0, but a warning is also raised. - If set to np.nan, such values will be excluded from the average.

    New in version 1.3: np.nan option was added.

`precision_recall_curve`, `roc_curve`, `roc_auc_score`, `average_precision_score `,  `label_ranking_average_precision_score`, despite having to compute precision or recall under the hood do not offer the same possibility.
While this is unlikely to pose problem in the micro averaging setting, it becomes more likely in the sample (AP and LRAP, possibly roc_auc_score)  or macro averaging setting.

For instance `precision_recall_curve` is not using the `precision_score` or `recall_score` functions:

https://github.com/scikit-learn/scikit-learn/blob/e4efd8b7961c1a16e862edc6c592e10dcd9d8697/sklearn/metrics/_ranking.py#L970-L985

In this implementation recall=1 and precision=0 when there is no positive example.

### Describe your proposed solution

Use the implemented `precision_score` and `recall_score` in all precision-recall and ROC curve functions. Add the same  `zero_division` kwarg and forward it to the `precision_score` and `recall_score` functions 

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

I think this discussion is linked to:

- #24381 that is associated to an unmerged PR. My proposed solution would also enable to fix this issue in a more consistent way (by returning a positive `0.0` and a a zero division warning)
- #19085

Also to add more context (though changing this could break some existing code): `roc_curve` and `precision_recall_curve` do not handle this problem consistently:
```python

import numpy as np
import sklearn.metrics as skmet

y_true = np.zeros(10)
y_pred = np.random.uniform(size=y_true.shape)

skmet.roc_curve(y_true,y_pred,pos_label=1)
# UndefinedMetricWarning: No positive samples in y_true, true positive value should be meaningless
#  warnings.warn(
# Out: 
# (array([0. , 0.1, 1. ]),
# array([nan, nan, nan]),  # Recall or True positive Rate
# array([1.82341255, 0.82341255, 0.0795866 ]))

skmet.precision_recall_curve(y_true,y_pred,pos_label=1)
#UserWarning: No positive class found in y_true, recall is set to one for all thresholds.
#  warnings.warn(
#Out: 
#(array([0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 1.]),  # Precision
# array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 0.]),  # Recall or True positive Rate
# array([0.0795866 , 0.3813231 , 0.41105316, 0.56378517, 0.56951648,
#        0.60346455, 0.61754398, 0.61861517, 0.70285933, 0.82341255]))

# Compute AUC for the the PR curve
prec, recall, thresh = skmet.precision_recall_curve(y_true,y_pred,pos_label=1)
skmet
# UserWarning: No positive class found in y_true, recall is set to one for all thresholds.
skmet.auc(recall, prec)
# Out: 0.5
```
Which translates into an undefined AUC for ROC and a weird `0.5` value (nor 0 nor 1) for the AUC of the PR curve. I also find the warning confusing, it states that Recall is set to 1 for all thresholds, however the last value of the recall vector is `0.`...

On the same theme I think the ndcg_score is also somewhat inconsistent (ideal DCG is 0.0, hence a zero division somewhere, in the binary relevance case without positive example): 
```python
y_true = np.zeros((10,5))
y_pred = np.random.uniform(size=y_true_almnull.shape)

skmet.ndcg_score(y_true,y_pred)
Out: 0.0
```
If one wanted to perform sample averaging of the three different metrics (though for the PR curve AP and LRAP are the way to go to perform sample averaging), they would all behave differently upon encounter of a sample with zero positive example...

COMMENT:
I have to admit I did not consider the plotting scenario, so I get your point here.

My perspective is more on the quantitative evaluation of performance, in publications, using the AUC. I think there is a general lack of transparency in the ML scientific research, and it is already hard sometimes to figure out whether the authors have used the PR or the ROC curve to compute the AUC, or even figure out the type of averaging, as some authors will write in their text "the AUC"... Thus, I have little hope to see in  publications a mention of what was done to handle such cases if only a warning is issued, and would actually even be in favor of raising an error by default to force the user to take a decision that is transparent in the code, if the code is made available.
If not raising an error I think returning `nan` is an equally good (if not better) option:
- since in general `nan` propagate to further computation the user will have to deal with it somewhat explicitly at some point
- the algorithm is not crashing

I see three problems with setting an extreme value (0 or 1):
- we actually have no information on the actual value, e.g we could return 0 with a given sample size, and the value could flip to 1 with just 1 extra example. This variation is not a sampling one, it is a bias.
- zero division actually is [mathematically undefined for real numbers](https://en.wikipedia.org/wiki/Division_by_zero)
- upon averaging setting a value for the undefined samples or labels will create a bias and either overestimate the metric or underestimate it. This bias will increase when the dataset size decreases upon macro averaging. By returning `nan` and performing `np.nan` the bias is likely to remain present (as chances are that the algorithm performs less well on classes with few positive examples), but I would expect that it would result in lower bias.

Labels: New Feature, Needs Investigation