Refactoring InferenceData as an AbstractDimTree

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`](https://rafaqz.github.io/DimensionalData.jl/stable/api/reference#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 `merge`ing.
- Faster compile times. Beneath the hood `DimTree`s are like ordered dicts, while `Dataset`s are liked `NamedTuple`s. 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 #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 https://github.com/rafaqz/DimensionalData.jl/issues/954#issuecomment-2752251439)