Add `from_turing` and `from_soss` to simplify getting auxiliary groups

[sethaxen]

As demonstrated in the Quickstart, generating prior, prior predictive, and posterior predictive samples for Turing and Soss, as well as log-likelihood values for Turing, is mostly boiler plate code that can be copied from the Quickstart by the user. We could eliminate the boiler plate for the user by adding from_turing and from_soss converters that take posterior samples as the first argument and an optional model keyword, e.g.

julia> from_turing(chains; model=param_mod, rng=Random.default_rng());

julia> from_soss(chain_or_multichain; model=param_mod, rng=Random.default_rng());

arviz.from_pymc3 takes a similar model keyword, which (I think) it only uses to compute log-likelihoods.

cc @cscherrer, @torfjelde

[cscherrer]

Thanks @sethaxen . I love the idea of cutting down boilerplate. In Julia it seems like we wouldn't need separate function names, since it could just dispatch on the types. Do you prefer not to do that to have the call syntax more similar to the Python version, or are there other reasons to do it this way?

Also maybe worth mentioning that in Soss we can manipulate the model to return things other than the samples themselves. So for example, instead of returning a sample from some distribution, we can return the distribution itself. For posterior predictive checks you then get a collection of distributions (one for each posterior sample), and you can do things like evaluate the quantile of the observed data for each value.

We don't need to cover all of that immediately, just mentioning it in case it helps in planning how this is designed.

[sethaxen]

Thanks @sethaxen . I love the idea of cutting down boilerplate. In Julia it seems like we wouldn't need separate function names, since it could just dispatch on the types. Do you prefer not to do that to have the call syntax more similar to the Python version, or are there other reasons to do it this way?

This is a good question. The current interface is very Pythonic, to parallel the Python package. So currently the from_XXX methods let us assume at least one output fits a certain package without assuming which one it is, while convert_from_XXX dispatches on the types but can also do a lot less. I am working on a more Julian interface that leverages dispatch and drops the from_ and convert_to_ prefixes as part of #128.

Also maybe worth mentioning that in Soss we can manipulate the model to return things other than the samples themselves. So for example, instead of returning a sample from some distribution, we can return the distribution itself. For posterior predictive checks you then get a collection of distributions (one for each posterior sample), and you can do things like evaluate the quantile of the observed data for each value.

So long as we dispatch to Python, I probably won't do anything with this, but perhaps when we do #128, then we can release some constraints on what a sample should be and revisit this.