This PR is addressing the forecaster base class proliferation discussed in #510, by simplifying the base class inheritance tree and the streamlining the private method logic.

Specifically, I've moved the logic from _SktimeForecaster and the forecasting horizin mixins into BaseForecaster, and adopted uniformly the principle of having a public method (fit, predict, etc) with checks/plumbing, dispatching to a "core logic" version (_fit, _predict, etc) where validated arguments can be assumed.

The burden on extenders becomes much lighter, since it is now possible to only focus on the "core logic" implementation, instead of having to keep in mind a myriad of inconsistent and constantly shifting conventions in checks and other plumbing.

As side effects, if we get this right, this should make a few things on the roadmap easier:

• the extension guidelines [DOC] Developer guide (extension guidelines and scitype templates) #464. Right now, the aforementioned implicit conventions are too many and intricate to write useful extension guidelines, in my opinion.
• extending to the multivariate case
• input/output checks and the eternal data container discussion, this can go in the plumbing

As a proof-of-concept regarding ease of extension, this PR also contains a highly annotated extension template in the extension_templates folder.

In terms of review, the key file is forecasting/base/_base, with corresponding changes (contraction and deletion) in base/_sktime.

I've tried to keep the interface consistent as much as possible (only changing internal logic).

Interface contracts with all the earlier estimators are still honoured, via loopthroughs and default behaviour that ensures that everything still works if fit, predict etc are overridden by the current descendants, as opposed to _fit and _predict.
The only change I had to made to descendants is set self._is_fitted=False at the start of fit, which is a minimally invasive change that's also separately reviewable as PR #941.

There should only be a single change that breaks the tagging/inspection interface, which is replacing the choice of which forecasting horizon mixin one inherits from with a choice of the new fh_in_fit tag (can be 'requried' or 'optional').
Temporarily, I've left both mixins and the _SktimeForecaster in and handled their behaviour as expected (inheriting from a mixin sets the fh_in_fit tag), so existing classes should still run, unless there is interface inconsistency or bugs in my refactor. Mid-term, we may want to remove the fh-mixins and _SktimeForecaster in favour of a single BaseForecaster class.