Dispatch aggregate

[TheooJ]

The goal of this PR is to dispatch aggregate, currently written in two files, by directly implementing it in _agg_joiner.py.

Following discussions with @Vincent-Maladiere and @jeromedockes, AggJoiner and AggTarget now require the operations parameter by default, and will try to apply all operations on all columns — as opposed to now, where columns are separated in categorical and numeric and only some operations are computed on each category.

I’m planning on doing follow ups to completely remove the _pandas.py, _polars.py, _namespace.py files, and on refactoring AggTarget with cross-fitting.

[Vincent-Maladiere]

Hey @TheooJ, very nice effort! Here is a first pass of comments.

On a higher level:

1. Since you use the CheckInputDataFrame class in AggJoiner.fit_transform, you should be able to remove the _check_dataframes method entirely. And since _check_inputs currently calls _check_dataframes, you have to place them in reverse order:

self._main_check_input = CheckInputDataFrame()
X = self._main_check_input.fit_transform(X)
self._check_inputs(X)

Additionally, the check_inputs method of the AggTarget could be simplified because CheckInputDataFrame does most of the checks.

2. You should add a get_feature_names_out method that returns self.all_outputs_ for both AggJoiner and AggTarget.

3. I think we should allow key, aux_key and main_key to be selectors.

[TheooJ]

Thanks a lot @Vincent-Maladiere !

To answer your points:

1. I can remove _check_dataframes and use CheckInputDataFrame, I just need to handle the case where aux_table="X" to keep the option of using the placeholder. I agree that AggTarget's check_inputs could be simplified, I plan on cleaning it in another PR (it's also missing some tests).
2. Sure ! Is it something to do here or in another PR ? Should we open an issue so that we add this method for other transformers like Joiner ?
3. I'm not sure we want this. On the one hand, it might be useful for long-term compatibility when selectors are public, so that people can either use list of cols or selectors directly. On the other, while I think it makes sense to say "compute the mean on all numeric columns", you are not going to join dataframes on all numeric or all string columns with key.

[Vincent-Maladiere]

1. and 2. can be done in this PR, it's not a huge change.

I agree that 3. use cases are rarer, but it looks weird to support selectors for the cols argument only. I might have keys that I can identify using regexes for instance, when the name of the column changes for whatever reason. Not a strong requirement, but it shouldn't be too costly to add.