Simplify and extend meta recommender logic

[AdrianSosic]

This PR refines the semantics of Meta recommenders and extends their use. It was motivated by two problems:

• First one arising in Move allow_* flags to Campaign #423 where pending_experiments should only be passed to BayesianRecommenders. Unfortunately, with the current meta recommender interface, it is not straightforward (or impossible?) to identify what exactly the next recommender will be – which indicates a suboptimal design.
• Second: fixes Unintuitive switching behavior of Meta-Recommenders in combination with Campaign #420

The important things changed:

• MetaRecommenders now have a much simpler logic, i.e. they only contain a select_recommender, which always just returns the recommender appropriate for the context of the call. Previous statefulness, which was only relevant to sequential recommenders, has been moved to the corresponding classes.
• They now have an is_stateful Boolean property
• They now have an get_non_meta_recommender method for extracting the appropriate context-specific non-meta recommender from the hierarchy
• They can now be composed of arbitrary other meta recommenders. The previous restriction that they need to be composed of pure recommenders was an unnecessary limitation. Allowing other meta recommenders as building blocks can indeed be indeed useful, for example, using a two-phase recommender where the second phase uses an adaptive (e.g. batch-size dependent) meta recommender.
• Added the new BatchSizeAdaptiveMetaRecommender, which can be useful, e.g. to avoid too costly optimizations for large batch sizes.
• TwoPhaseMetaRecommender now has an explicit remain_switch option to clarify its behavior.

[AdrianSosic]

@AVHopp @Scienfitz
Note, I've just added one more commit introducing a get_inner_recommender method, which is useful for #423.

[AVHopp]

Incomplete review since there was another issues that required my attention, but still a first bunch of comments.

[AVHopp]

Last bit of my review that was still missing.