Refactoring InferenceData as an AbstractDimTree

[sethaxen]

With Python arviz v1.0, the InferenceData type is completely dropped in favor of xarray's own DataTree (see https://arviz-base.readthedocs.io/en/latest/tutorial/WorkingWithDataTree.html). Here I propose refactoring InferenceData as a subtype of the analogous DimensionalData.DimTree. Instead of using a DimTree directly, we'll probably want to implement our own AbstractDimTree subtype that we can use for dispatch.

Benefits of switching to DimTree include:

• Mutability. Users can incrementally add groups to an InferenceData instead of doing it all-at-once or in stages and then mergeing.
• Faster compile times. Beneath the hood DimTrees are like ordered dicts, while Datasets are liked NamedTuples. As a result, the same method operating on a Dataset will be faster (and probably type-inferrable), while it will have much longer compile times. In practice this lag from JIT-compiling is very noticeable, so in Reducing compilation time with InferenceData #15 I recommended sacrificing type-inferrability for improved interactive usability.

Downsides include:

• Return types would be generally non-inferrable. This is acceptable for reasons discussed above.
• DimTree is currently experimental and can change at any time. This blocks this proposal; however, if we implement a draft PR where we stress-test DimTree, that might be enough to get it deemed non-experimental (see Nested xarray.DataTree-like containers rafaqz/DimensionalData.jl#954 (comment))

[sethaxen]

Missing features from AbstractDimTree include:

• converting a leaf-only AbstractDimTree to AbstractDimStack (before passing to expensive methods where speedy access is critical)
• implements Tables interface