[DOC] better package description in readme - what are skbase "patterns"

[fkiraly]

I think the readme and landing page should describe more clearly what patterns skbase provides.

I would go with an abridged version of the BaseObject design document, from here
https://github.com/sktime/skbase/pull/76/files

Here's an unabridged copy-paste:

---

BaseObject

BaseObjects are base classes with:

• scikit-learn style interface to get and set parameters
• sktime style interface for working with tags
• • sktime style interface for cloning and re-instantiation (resetting)
• sktime style interface for generating test instances
• sktime style interface for retrieving fitted parameters
• scikit-learn style interface for representing objects (e.g., pretty printing
  and drawing a simple block representation in HTML)
• Support simple composition where parameter arguments are other BaseObjects,
  including the ability to get and set the parameters of component BaseObjects
• Interface for instance-level override of configuration context
• Interface for parameter validation.

BaseObjects should also follow certain design patterns and coding practices,
including:

• Specify all parameters in the classes __init__ as explicit keyword arguments.
  No args or kwargs should be used to set class parameters.
• Keyword arguments should be stored in the class as attributes with the same name.
  These should be documented in the parameters section of the docstring, and not
  documented in the attributes section of the docstring.
• All instance attributes should be created in __init__. If the attribute
  is not assigned a value until later, initialize it as None.
• Attributes that depend on the state of the instance's parameters should end
  in an underscore to easily communicate that they are "state" dependent.
• Start non-public attributes and methods with an underscore
  (per standard Python conventions).
• Document all public attributes that are not parameters in the class docstring's
  attributes section.

[fkiraly]

(bit of a mix of features and design contract specification - I would recommend to abridge to self-contained list of features)

[RNKuhns]

Agreed that this will be nice to have. I think we can get this into a usable format and included in v0.4.0 pretty easily.