Option to return non-standardized AUC value when `max_fpr` is set for BinaryAUROC

Nobody has claimed this yet.

## 🚀 Feature

Adding a simple keyword argument to control where McClish's standardization is applied over AUC or not. Alternatively, could return a pair of standardized and non-standardized AUCs when the argument is set.

### Motivation

Currently, `BinaryAUROC` only returns the standardized AUC according to McClish's method. However sometimes the non-standardized version might be requested. In my specific case, when I set `max_fpr` to `0.2` I was not expecting `BinaryAUROC` to return values over `0.2` to me as I expected `0.2` to be the theoretical max pAUC.

### Pitch

Instead of offloading the process of de-standardizing the pAUC scores to the user, this can be done within `torchmetrics` with the addition of a simple keyword argument. Furthermore, the existence of this keyword argument and it's corresponding docstring entry makes it more concise to the user what kind of output they should be expecting from the method. Additionally, the docstring should explicitly explain what the *standard* AUC means by either providing an external link or preferably by providing the actual formulation of the standardization process.

### Alternatives

The de-standardization process can be done out-of-the-box by the user by reverting the normalization process described by McClish, 1989. This has two immediate drawbacks:

- Reverting the standardization can cause mildly significant and unnecessary precision error propagation.
- The de-standardized score is already calculated and readily available in the current implementation, it simply needs to be returned per user's needs with minimal changes to the code and without introducing any breaking changes.

### Additional context

I would be happy to submit a PR for this myself if the pitch is approved

Start at the BinaryAUROC entry point and trace how max_fpr currently produces the standardized partial AUC. Compare the requested keyword-argument behavior with the alternative of returning both values, and document the McClish standardization clearly. Done means the chosen API exposes the non-standardized value when requested without breaking existing standardized results.

Written by the indexing model from the issue text.