Implement likelihood/posterior distinction (in output of estimators and ingestion in summarizers)

[MarkusMichaelRau]

Not all summarizers are compatible with all types of estimators. RAIL implements methods that are conditional density estimates; others evaluate likelihoods. Summarizers that deconvolve individual galaxy redshift likelihoods would not necessarily be compatible with conditional density estimates. Similarly, summarizers that expect conditional density estimates would not give sensible results for likelihoods.

Ensuring that a summarizer can only be used with a correct estimator would be helpful. This could be maybe ensured using a factory pattern for summarizers and estimators.

[aimalz]

The fix for this isn't necessarily about the estimator -- BPZ with a nontrivial prior still yields a posterior rather than a likelihood -- so the software fix corresponding to this issue is to associate metadata of "likelihood" (as opposed to "posterior" or None) with the qp.Ensemble output by an estimator when it is run such that likelihoods are produced (and I think the only estimator we have that can do that right now is BPZ when given a flat prior). Then the varInference summarizer would need to check that its inputs contain this metadata.

[aimalz]

Note: when this issue is closed, a new issue should be created for wrapping CHIPPR as another summarizer.

[aimalz]

As per discussion with @sschmidt23, this boils down to RAIL estimators associating a keyword to their output ensembles for "likelihood" or "posterior," but it touches on the related requirement for #14 to have creators and estimators associate "reference" or "estimate" to their output ensembles to be checked before calculating certain metrics.

[jlvdb]

I would like to add to this particular issue and mention that my yet_another_wizz wrapper produces jackknife samples, which have a different variance than bootstrap samples that one might naively expect. For now I will just tag the resulting Ensembles with some metadata that indicate this fact.