[ENH] inter-scitype adapters for estimators and default coercions

[fkiraly]

We are seeing more and more examples where an estimator of one scitype should be considered as another, in composition.

Examples:

• using a clusterer as a transformation, in the TransformSelectForecaster - https://github.com/sktime/sktime/pull/6848
• using a clusterer as a transformation, in pipelines
• using sklearn transformations as time series transformations, via TabularToSeries adapter.
• using a forecaster as a transformation, via in-sample forecasts.
• using a time series aligner that can produce distances as a time series distance, via DistFromAligner
• using a time series annotator - outlier, changepoint detector - as a transformation. This is even parametric, depending which output we map onto score. #6591

I think the cleanest way to address these would be:

• write coercion wrappers for the individual transformation
• write a coercion layer, that collects standard ways to coerce objects of scitype X to objects of scitype Y.
  • the coercion layer could be attached to a to_scitype method that all base classes possess.
  • This would allow any user to pass more scitypes without explicit coercion, and developers to write more flexible composites by prefacing with a `to_scitype coercion.

[fkiraly]

FYI @Alex-JG3 re annotation. This could allow us to eat our cake and keep it, as the coercion to transformation would be silent.

[fkiraly]

FYI @sktime/core-developers

[Alex-JG3]

I like this concept. Would the coercion wrappers require strict adherance to the base classes? Currently there are several annotators that don't quite adhere to BaseSeriesAnnotator which would make coercing them from type annotator X to type Y difficult.

It would be good to know if this is an issue in other parts of sktime.

[fkiraly]

@Alex-JG3, yes, this would of course require strict API compliance to work, like any kind of composition or reduction. Afaik sktime is the only package in the time series space that has strictly enough enforced APIs for it to enable complex composition. Except the annotation module, currently... but I hope we'll get there 😃

More explicitly, noncompliance with API specifications is not a problem in other parts of sktime, all other modules are more mature.

The reason for this is probably the different types of estimators under a single umbrella - anomaly detectors, changepoint detectors, segmenters, etc. Besides being complicated to define what these actually are on an API level, confusion is common, even in academic literature. Which is an explanation but not an excuse, of course.