MAINT Split `Splitter` into a `BaseSplitter` and a `Splitter` subclass to allow easier inheritance

### Summary
With #24678, we make it easier for the `Criterion` class to be inherited. However, the Splitter class can also leverage this improvement. We should separate the current `Splitter` class into an abstract base class for "any type of splitting" `BaseSplitter` and an abstract supervisededly splitter class that requires `y` labels `Splitter`. By keeping the names the same, this change is mostly backwards-compatible.

Moreover, we should refactor what `criterion.init` does into its two intended functionalities: i) setting data and ii) moving pointers around and updating criterion statistics.

### Proposed improvement
Based on discussion below, we want to preserve the `y` parameter passing chain of `Tree -> Splitter -> Criterion`. With the exception of `splitter.init`, all other functions can and should be part of the base class without any notion of whether or not the splitter is supervised, or unsupervised. In order to achieve this, we need to separate where `y` is passed to the criterion (currently it is done within `node_reset`.

1. Refactor `criterion.init` into two functions for initializing the data and resetting the pointers (https://github.com/scikit-learn/scikit-learn/blob/b728b2e8b192857f3522007328fa66909ed68787/sklearn/tree/_criterion.pyx#L44-L69):
i) `criterion.init(y, sample_weight, weighted_n_samples, samples)`, which initializes the data for criterion.
ii) `criterion.set_pointer(start, end)`, which sets the pointers to the start/end of the samples we consider
2. Refactor `splitter.init` to pass the value of `y` to the criterion via the new `criterion.init` function (https://github.com/scikit-learn/scikit-learn/blob/b728b2e8b192857f3522007328fa66909ed68787/sklearn/tree/_splitter.pyx#L96)
3. Refactor `splitter.node_reset` to call `criterion.set_pointer` instead of `criterion.init`. (https://github.com/scikit-learn/scikit-learn/blob/9c9c8582dff9f4563aa130ef89f155bad0051493/sklearn/tree/_splitter.pyx#L180)
4. Refactor `Splitter` into `BaseSplitter` and `Splitter` class. The `BaseSplitter` will contain all the methods except for `init`. `Splitter` will subclass `BaseSplitter` and require the `init` function.

This makes Splitter easier to subclass and also removes some of the interdependency of parameters between Tree, Splitter and Criterion.

Once the changes are made, one should verify:

1. If `tree` submodule's Cython code still builds (i.e. `make clean` and then `pip install --verbose --no-build-isolation --editable .` should not error out)
2. verify unit tests inside `sklearn/tree` all pass
3. verify that the asv benchmarks do not show a performance regression.

`asv continuous --verbose --split --bench RandomForest upstream/main <new_branch_name>` and then for side-by-side comparison `asv compare main <new_branch_name>`

### Reference

As discussed in #24577 , I wrote up a doc on proposed improvements to the tree submodule that would:
1. make it easier for 3rd party packages to subclass existing sklearn tree code and
7. make it easier for sklearn itself to make improvements to the tree code with many of the modern improvements to trees

cc: @jjerphan 

@jshinm I think this is a good next issue to tackle because it is more involved, but does not require making any backward incompatible changes to the sklearn tree code.

COMMENT:
> What is the concrete friction here?

My main motivation is making the tree class more easily subclassable for other tree models. For example, when we discussed in the monthly dev meeting, there are quantile trees, honest trees, survival trees, oblique trees, unsupervised trees and more. The main reason that they are not included is the maintenance burden due to the tree code not being easy to work with. 

For this specific setting, the friction arises if one tries to leverage splitter and criterion code for an unsupervised tree model. In #24577 I advocate for making a base class for criterion to make code more modular and abstract. In this, I want to extend that notion for Splitter. Right now the Splitter claims to be abstract, yet in the `init` code by passing in `y`, it explicitly assumes it is supervised. However, a tree splitter's job is simply splitting "X". Criterion measures the values of those splits via some function of X, y, or combination of the two (in sklearn currently, it is done only as functions of y). 

Another concrete example of how the `Splitter` class is not truly "abstract" modular base class is in splitter.node_reset, we might expect the node to reset the pointers and the values within criterion. However, it re-initializes `y` every time as well. This implicitly like the Criterion, assumes it is supervised. 

```
cdef int node_reset(self, SIZE_t start, SIZE_t end,
                        double* weighted_n_node_samples) nogil except -1:
        """Reset splitter on node samples[start:end].

        Returns -1 in case of failure to allocate memory (and raise MemoryError)
        or 0 otherwise.

        Parameters
        ----------
        start : SIZE_t
            The index of the first sample to consider
        end : SIZE_t
            The index of the last sample to consider
        weighted_n_node_samples : ndarray, dtype=double pointer
            The total weight of those samples
        """

        self.start = start
        self.end = end

        self.criterion.init(self.y,
                            self.sample_weight,
                            self.weighted_n_samples,
                            &self.samples[0],
                            start,
                            end)

        weighted_n_node_samples[0] = self.criterion.weighted_n_node_samples
        return 0
```

It seems unnecessary and doesn't match what the docstrings of the `criterion.init` and `splitter.node_reset` say. Moreover, it does not allow one to leverage `criterion.node_reset` code.

Labels: module:tree, cython, Refactor