Introduce BestPracticeWarning to help users with their learning curve

[michaelosthege]

What is this about

Many things are possible with our API.
Some of those are supported.
Some uses of the API are encouraged, others discouraged and about most even the experienced PyMC folk disagree.

One might ask

Why not deprecate those things which are discouraged?

The answer is a mix of

We can't agree on that.

The encouraged API is too confusing for beginners.

One example:

# This is "beginner friendly" plotting of a trace.
# It hides the fact that `plot_trace` actually originates from another library: ArviZ
pm.plot_trace(idata)

# The best practice is to not confuse the two packages:
import arviz as az
az.plot_trace(idata)

Another example:

with pmodel:
    # The old, but discouraged use of MultiTrace
    trace = pm.sample(return_inferencedata=False)

    # We encourage everybody to work with InferenceData, because reasons (1,2,3,4)
    idata = pm.sample(return_inferencedata=True)

^{[1]: We'd like to eventually refactor/remove MultiTrace internally. The fewer people use it, the easier that will be.
[2]: InferenceData objects can be saved/loaded to disk in a consistent format without security implications. That's just better scientific practice.
[3]: Plotting and diagnostics with ArviZ use InferenceData objects already. Migrate prediction/plotting code to InferenceData means that data analysis workflows become more reproducible.
[4]: Working with InferenceData is even more fun and robust when combined with dims/coords, which is another encouraged flavor of working with PyMC3.}

How it can be done

A BestPracticeWarning can be added to pm.exceptions and imported at the package level.

With warnings.simplefilter("ignore/once/always/error", BestPracticeWarning) the warnings can be customized, for example to always raise them in Jupyter notebooks.