Transformer for nominal categories, with the goal of improving category support in decision trees

I'd like to find out how keen people would be for adding a transformer like this.

### Describe the workflow you want to enable

Improved support for nominal categories in tree based models. Nominal categories are ones with no order to them, for example colour or country (c.f. ordinal categories that are ordered).

### Describe your proposed solution

In #12866 @amueller linked to [Splitting on categorical predictors in random forests](https://peerj.com/articles/6339). This proposes to replace categorical values (red, green, blue, ..) by cleverly computed numerical values (blue -> 0.643, green ->0.123, ...) that allow you to achieve similar/equal performance by using `<` as splitting decision in a tree node compared to performing an exhaustive search of all possible categorical splits.

I would implement this as a transformer that you use together with a random forest or other tree based model in a pipeline.

### Describe alternatives you've considered, if relevant

There have been several PRs attempting to add native category support to decision trees. #12866 is the latest one. My impression is that it would be cool to have this in trees but that it is not easy to do, several people have tried but no PR has landed yet. The "Breimann trick" that is used is also limited in the number of categorical values it supports, where this new idea seems to support unlimited categorical values and multi class classification.

### Additional context

An earlier paper that is cited in "Splitting categorical predictors...": https://link.springer.com/article/10.1023/A:1009869804967

An open question for me is how to measure how good this kind of transformation is compared to the exhaustive split (which is "the best possible" but too expensive to compute to be used in practice). The method proposed by the paper seems simple (famous last words), and they make claims about the performance but it would be nice to know how close this gets us. Trust, but verify ;)

COMMENT:
> So we need a way to solve that, some form of splitting the data like the cuml TargetEncoder does?

Yea, the implementations of `TargetEncoder` that do not leak target data are the ones that splits the data multiple times during training. In the past, I ran benchmarks that shows that data splitting is **required** for `TargetEncoder` to work. There is [also this benchmark paper](https://link.springer.com/article/10.1007/s00180-022-01207-6) that concludes the same thing.

For reference, here are some repos containing benchmarks from different sources:
- https://github.com/DenisVorotyntsev/CategoricalEncodingBenchmark
- https://github.com/jorisvandenbossche/target-encoder-benchmarks
- https://github.com/thomasjpfan/sk_encoder_cv (I experimented with some target encoding schemes trying to keep `fit.transform == fit_transform`. None of these experimental encoding schemes fit in scikit-learn, because we do not to invent anything here).

With the data splitting, we will unfortunately end up with `fit(X, y).transform(X) != fit_transform(X, y)`. During `fit`, the training data is split such that a subset of the data is used to encode the categories in the other subset. At the end of `fit`, all the training data is used to encode the categories, which is used during prediction time.

**TLDR**: If we include a target encoder in scikit-learn, it likely will be the one that splits the data in `fit` where `fit.transform != fit_transform`. This breaks our API convention, but it is required for a target encoder to work. In our [glossary entry for fit_transform](https://scikit-learn.org/dev/glossary.html#term-fit_transform), we do allow for this inconsistency.

Labels: New Feature