Initial Adaptive Grid prototype

[danrbailey]

Sharing an initial Adaptive Grid prototype. In this case, it's not even a dense grid, it just contains a single background value and I've done the minimal work to make this compile with most of the required methods set to throw a not implemented error currently. No IO implemented. Some brief notes:

I'm using an adaptive:: namespace, this sits within an openvdb/adaptive sub-directory and I'm calling this AdaptiveTree. It derives from TreeBase as we discussed and this is nested within a Grid as well and aliased to AdaptiveGrid.

I've introduced a new AllGridTypes alias that adds AdaptiveGridTypes to SparseGridTypes. Adaptive Grids are registered, but existing methods that call grid.apply<GridTypes>() will not apply to new Adaptive Grids and will have to be intentionally extended if that is the desired behavior.

I introduced a new TreeTraits class to determine whether grids are adaptive or sparse and added a specialization to the relevant template classes. The main goal here was to not need to add new virtual methods or static member variables to the Tree class (or any other derived classes there might be in the wild). I've added logic to the interpolation routines to handle sparse vs adaptive trees, which can then be used in the PointAdvect class without further changes.

BoxSampler::sample(const TreeT& inTree, const Vec3R& inCoord,
                    typename TreeT::ValueType& result)
{
    ....
    if constexpr (isSparseTree<TreeT>()) {
        // sparse implementation
    } else if constexpr (isAdaptiveTree<TreeT>()) {
        // adaptive implementation
    }
    OPENVDB_THROW(NotImplementedError, "");
}

This should be sufficient to get some conversation going as to how this kind of thing could work. It might make sense to consider using an impl sub-directory as we have done elsewhere, but where should the implementation for sparse trees and adaptive trees live? Should we just include both implementations in the body of this function as I've done here? Should we add a new sparse sub-directory and put the original implementation of this method there and then put the adaptive one in the adaptive sub-directory? How would this work for some of the much larger, more complicated methods? What about if we added more logic for handling dense trees? How is this going to work with explicit template instantiation?

[danrbailey]

This PR should pass all the CI checks when #1775 and #1776 are merged in.

@kmuseth - to follow up on one of your questions from the meeting yesterday. The ValueAccessor registry stores the ValueAccessorBase which means any variant of the ValueAccessor will be registered provided that it derives from this base class:

https://github.com/AcademySoftwareFoundation/openvdb/blob/master/openvdb/openvdb/tree/Tree.h#L1016

Moving the accessor alias and ValueAccessor construction from the Grid to the Tree does not affect the registry in any way. Finally, this registry is stored on the tree and not the grid, so for an adaptive tree there is no registry needed as implemented.

[zap150]

@danrbailey is there any ETA or roadmap for this feature? Also, can you disclose what structure will be used for the adaptive volume (tree, sparse grid, already existing implementation outside of OpenVDB, papers...)?