Add `strata` to `Stratified*Split` CV splitters

Right now `Stratified*Split` classes take `y` as the strata, while that's not always the case.

In `train_test_split` we allow a `stratify` arg (which I'm wondering if it should be called `strata`), which defines the groups samples belong to. And inside, we basically do this:

```py
    cv = StratifiedShuffleSplit(test_size=n_test, train_size=n_train, random_state=random_state)

    train, test = next(cv.split(X=arrays[0], y=stratify))

    return list(
        chain.from_iterable(
            (_safe_indexing(a, train), _safe_indexing(a, test)) for a in arrays
        )
    )
```

As you can see, we're passing `stratify` as `y` to the splitter. I think it would make sense to add a `strata` arg to the splitters, and if `None`, we'd take values in `y` instead, as it is now.

Note that now that we have SLEP6, we won't need a separate class for them, and we'd simply request `strata` for the splitter:

```py
cv = StratifiedShuffleSplit().set_split_request(strata=True)
...
GridSearchCV(model, param_grid, cv=cv).fit(X, y, strata=strata_values)
cross_validate(model, X, y, cv=cv, props={"strata": strata_values})
```

cc @marenwestermann

COMMENT:
Nice @ArturoAmorQ! 

I'm afraid I didn't quite get enough time last week to get a synthetic example together to a shareable standard, however...

I'm aiming for the same kind of argument with a healthcare application. There, one will usually be expected (if not for ethical, then for regulatory reasons) to have suitable representation of a number of categorical features (race, age groups, sex), both in the training set and the evaluation set. Usually these categories are very imbalanced: sometimes due to the fact that a subpopulation might be a small proportion of an overall population; sometimes because it is harder to get some subpopulations to consent to having their data used; (+other reasons...). This imbalance means that stratification is necessary in order to guarantee representation of the subpopulations.

Regarding of the precise statistical need that subpopulation-stratified CV would satisfy (and because I'm not a expert on sampling), I'll step back for a second, and pose a few questions with some brief answers:

+ What we do simple random CV for: this is usually because we want a data efficient method of estimating the expected prediction error (defined according to some loss) of a model.

+ Why do we do class-(/y-)stratified CV? I'm not so clear on the precise statistical need that this satisfies. Practically, this is often done to guarantee representation of objects that we wish to classify, where objects are defined by their class (y). We induce class distribution leakage between train and evaluation, so it seems there should be a cost to generalisation.

+ Why would we want to do subpopulation-(/feature-)stratified CV? A couple of the statistical needs here are represented by the items mentioned [here](https://en.wikipedia.org/wiki/Stratified_sampling#Advantages), particularly 1: _If measurements within strata have a lower standard deviation (as compared to the overall standard deviation in the population), stratification gives a smaller error in estimation._. Additionally there are the practical needs of representing the subpopulation, which will usually involve computing metrics over all subgroups, which may be undefined if members rarely find their way into the evaluation splits. I don't think the logic here is significantly different from that of class-stratified CV, except that we are thinking of subpopulations as defining objects, rather than class labels.

I haven't had a huge amount of luck searching ML papers addressing these points from a theoretical perspective, but am keen to continue exploring. If anyone else already has a better understanding of the precise statistical situation, would love to hear.

Labels: New Feature, RFC