RFC Deprecate FeatureUnion and make_union

Unless I'm missing something, to me `FeatureUnion` is just a `ColumnTransformer` where all transformers are applied to all features. So it's just a special case of `ColumnTransformer`.

```py
import pandas as pd
from sklearn.pipeline import FeatureUnion
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler

df = pd.DataFrame({"a": [1, 2, 3, 4], "b": [1, 2, 3, 4]})

fu = FeatureUnion([("std_1", StandardScaler()), ("std_2", StandardScaler())])
fu.set_output(transform="pandas")
print(fu.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641

all_cols = slice(None)
ct = ColumnTransformer([("std_1", StandardScaler(), all_cols), ("std_2", StandardScaler(), all_cols)])
ct.set_output(transform="pandas")
print(ct.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641
```

In addition, the parameters of `FeatureUnion` is a subset of the parameters of `ColumnTransformer`, so I don't see anything that one would be able to do with `FeatureUnion` but not with `ColumnTransformer`.

From a maintenance view, it duplicates the burden because they share almost no code and it's common that they suffer from the same bugs and  fixes have to be repeated in both classes. And usually one or the other keeps the bug for a while because we only implement a fix for one and forget about the other. In general the forgotten one is `FeatureUnion` btw :) (e.g. the latest one https://github.com/scikit-learn/scikit-learn/issues/32104 for `FeatureUnion` that was detected and fixed a while ago for `ColumnTransformer` https://github.com/scikit-learn/scikit-learn/issues/28260)

Finally, `FeatureUnion` has unresolved long standing issues like not cloning the transformers before fitting and modifying init parameters during fit, meaning that it does not follow our Transformer API.

Considering all that, I propose to deprecate `FeatureUnion`.

ping @scikit-learn/core-devs, did I miss something obvious ? what's your opinion about that ?

COMMENT:
@thomasjpfan I have used the `FeatureUnion` ever since I can remember and never really got my head around the `ColumnTransformer`. The syntax never really clicked and I find the "select" approach ([skrub](https://skrub-data.org/stable/reference/generated/skrub.SelectCols.html), [scikit-lego](https://koaning.github.io/scikit-lego/api/preprocessing/#sklego.preprocessing.pandastransformers.ColumnSelector)) much easier to default-remember, which works really well with the `FeatureUnion`.

 The feature union, in my mind, merely does one thing ... it concatenates features. The `ColumnTransformer` selects *and* transforms. In my mind those are two seperate steps and should also have two seperate lego bricks to click together. For scikit-pipeline it also feels much more natural to use a `make_union` for the plus operator.

I would object the removal of this feature, but that's personal.

Labels: API, RFC, module:compose, module:pipeline