Split out grid interface (`CR.Trees`) to separate package.

[asinghvi17]

Why do this?

• Reusability and a lighter dependency for grid providers
• Split grid API and formalize it, so we cannot rely on any hacks here
• Other consumers like Geomorphometry.jl etc may want to rely on this

The idea

I initially implemented the treeify function as the entry point. But there is a lot of information that is only (efficiently) available in the actual grid, like:

• connectivity between cells
• cell centers
• the dual grid (delaunay triangulation vs voronoi tessellation)
• parent cells for hierarchical dggs

That being said there is a significant amount of pre-processing that needs to be done as well to convert a grid to a tree. Perhaps the better solution is to construct all members of the grid and then simply provide what are now STI.children(treeify(grid)) as STI.children(grid).

I think we have 3 semantically separate APIs here:

• Mesh API (neighbours mainly) - can use accelerations from tree and hierarchy APIs but fundamentally does not care about them
• Tree API (descend the tree and perform spatial tree search) - cares only about parent child relationships not the other way around. Does not require hierarchy
• Hierarchy API - only for hierarchical dggs, not required. Parent -> child idx and child -> parent idx. Idx can be a special object describing the index,and level. Not sure what one would use this for - perhaps chunking?

[asinghvi17]

I'll update this tomorrow to be more coherent, just wanted to write my thoughts down resulting from discussion with @evetion