Less strict subtyping in `ProbabilitiesEstimator`s about complexitymeasures.jl HOT 2 CLOSED

Well, this means that the probabilities estimators design is wrong. They should NOT have outcome spaces as fields in the first place. Why do they? A probability estimator is entirely agnostic to the outcome space. It only sees counts. It was a wrong decision to have them as fields. In general, we often follow too much of an object oriented approach instead of the more Julian finction based and multiple dispatch. Too often we make things fields of other things, when they should be arguments to functions instead.

In any case, here it is scientifically conceptually clear that the call signature must be

probabilities(o::OutcomeSpace, x)
probabilities(est::ProbEst, o::OutcomeSpace, x)
probabiities(est::ProbEst, counts_or_probabilities)

where the first signature calles RelavtiveAmount and then calls the second signature. The second signature is a generic implementation that does not depend on est or probs and calls either counts or probabilities depending on if o is count-based. So only the third method has speciifc impleentations.

The probabilities estimators don't have a reason to reference an outcome space.

from complexitymeasures.jl.

Agreed. I'll make a PR implenting these changes asap.

from complexitymeasures.jl.