[ENH] remove fit_params kwargs throughout the code base

[fkiraly]

As pointed out by @Vasudeva-bit, some estimators were still using a fit_params kwarg in _fit.

This is non-compliant with the interface spec, but did not cause any errors since never anything was passed by kwargs.

This PR simply removes any fit_params kwargs and concomitant logic from the code base.
Needs no deprecation, since:

• the interface spec is clear and the args occurred only in private functions, with one exception.
• evaluate had the arg, but when used it would error out since no fit actually had the arg, so deprecation is also not necessary here (because we are changing from an "error causing argument" to "no argument", hence no one will have relied on it).

Since this seems to be a frequent issue for extenders, I've added a paragraph to _fit in the classification, forecasting, and transformer extension templates (where it is most likely encountered due to interfacing as opposed to implementation from scratch).

[aiwalter]

Did you check what those params could have been? We might add them to constructor as we did for statsmodels in another PR

[fkiraly]

Did you check what those params could have been?

As far as I saw, only occurred in compositors, and logic passing the kwargs from composite interfaces to component interfaces.

Plus pmdarima, I'll open an issue for it: #2344

[aiwalter]

I checked for Prophet, and yes that **kwargs in _fit() were actually not reachable due to inner call in fit()

[fkiraly]

@aiwalter, are there any Prophet args which we are missing due to this?

[fkiraly]

Added prophet to the issue #2344

[fkiraly]

@aiwalter, this has now come up so often, I've added a paragraph to extension templates in _fit - do you think that's a good idea?

[aiwalter]

yes, seems many dependency packages are doing this, so we have to add it to constructor. Makes sense to add it to template. Thx