Full type hints for the module base

[e10e3]

Continuing #1592, this PR adds type hints for the basemodule.

I am not entirely familiar with the code, so we may have things to adjust. Hence, I start with a draft.

Because the PR is quite big, I tried to have clean commits, you can use them to help the review.

Notable changes:

• I changed the regression target to float, because Python's type pyramid recommends not to use the numbers module for type annotations. And MyPy doesn't support it anyway.
  Also, numers.Number also includes complex numbers, but I am confident saying all the code expects floats. Integers are converted automatically to floats if needed.
• Where transformers are used, the annotation is now BaseTransformer to allow all transformers, not just the supervised ones.

A few things I would like to discuss before leaving the "draft" status:

• The Estimator Problem: many functions expect a generic model that has the predict_* and learn_* methods, but there is no single type representing this capability.
  I tagged them as requiring an Estimator, but this is not satisfactory.
  Should we:

  • Enumerate all possible types every time (Classifier, Regressor, Clusterer, Pipeline)
  • Create a Protocol (a Python interface) for models that can learn, predict, and do both
  • Create a new abstract class that introduces learn_* and predict_*

• The Ensemble class inherits from UserList. Because it is an implementation of the list type, it is mutable, leading it to be type-invariant. Since Ensemble is now typed with Estimator, all models are bare estimators. An ensemble of Hoeffding trees would not be able to access the HT-specific methods (even things like learn_one!) without violating the typing -- runtime behaviour is not impacted, Python is dynamic.

[MaxHalford]

Thanks for the info about numbers.Number, makes sense 👍

The Estimator Problem: many functions expect a generic model that has the predict_* and learn_* methods, but there is no single type representing this capability.

I like the typing.Protocol solution, it's modern and probably the right solution here.

The Ensemble class inherits from UserList (but only partially implements its methods). Because it is an implementation of the list type, it is mutable, leading it to be type-invariant. Since Ensemble is now typed with Estimator, all models are bare estimators. An ensemble of Hoeffding trees would not be able to access the HT-specific methods (even things like learn_one!) without violating the typing -- runtime behaviour is not impacted, Python is dynamic.

We could definitely simplify here: we don't have to inherit from UserList. We could instead implement the necessary methods manually. We could also define an option to make the list appendable or not.