Featurizer refactoring

[Olllom]

As we discussed in person, PR #7 is merged leaving a few desiderata for the future. Here is a list of open points:

• dangling return statements in Featurizer.add_... methods should be removed
• some Featurizer.add_... docstrings state falsely that the method returns the data
• Featurizer should not have the reference ensemble as a field. Instead, it should have a state that can be read from an h5 file, which can contain reference structures, TICA coordinates, etc.
• instead of excluding bins from the divergence computation, I would instead set a minimum base density as done by Aleks in the force optimization paper.
• Inclusion of TICA MSE and Jeffrey's divergence would be nice to complement JS and KL
• TICA construction with deeptime should be moved to a different function (maybe we could establish a Featurizer.register_... framework alongside .add_... and .get_...; with new methods Featurizer.register_TICA(lagtime) as well as Featurizer.register_reference_structure(frame, structure_name) etc.

[iryna-zaporozhets]

Would it be better to make Featurizer a stateless collection of methods that takes an ensemble and some additional parameters and then augment the ensemble with some features/give it to users? In EnsembleQualityMetrics currently, only the static method Featurizer.get_features() is used. The exact details of featurization can be passed directly to EnsembleQualityMetrics, and the suggested register_reference_structure and register_TICA can be implemented there.

[nec4]

I think this issue should be closed as of #13, but I could use a second opinion.