re-factoring existing forecasters to new interface

We need to slowly re-factor all forecasters to be compliant with the new interface (see PR #912). i.e., no overrides of fit etc and descendant classes only implementing core logic, while the BaseForecaster implements check etc logic.

Currently this is running due to various downwards compatibility workarounds, which should be removed once all forecasters are ready (in “no-override” state)

The forecasters that still need a downstream refactor are:

• NaiveForecasters #953
• EnsembleForecaster #977
• MultiplexForecaster #977
• TransformedTargetForecaster #977
• _Reducer and related code #1031
• StackingForecaster #977
• ForecastingGridSearchCV, RandomizedGridSearchCV, and BaseGridSearch #1034
• OnlineEnsembleForecaster and descendants #1015
• _PmdArimaAdapter and descendants ARIMA, AutoARIMA #1016 - adapter only
• BATS, TBATS, and _Tbatsadapter #1017 adapter only
• _StatsModelAdapter and descendants AutoETS, ExponentialSmoothing, ThetaForecaster #1029
• HCrystalBallForecaster #1004
• Prophet and _ProphetAdapter #1005
• PolynomialTrendForecaster #1003

For a how-to, useful resources are the forecaster extension template in extension_templates and PR #953 as an example for NaiveForecaster.

Based on discussions, we need to do the following two things in a capstone refactor that removes the last traces of the workarounds and goes over the above for consistency:

• remove the _SktimeForecaster and mixins for good
• go through all forecasters and check the tags for correctness

[Lovkush-A]

@fkiraly. As a third item, I suggest getting rid of _sktime.py altogether. The only things in there are _SktimeForecaster (to be deleted), the mixins (to be deleted) and _BaseWindowForecaster (which I suggest moving into _base.py).

I also suggest refactoring _BaseWindowForecaster but it is better to do that in #982 as BaseWindowForecaster predominantly deals with defining predicts and updates

[fkiraly]

Yes, indeed.