Adjust existing grid API to move ValueAccessor methods to the tree

[danrbailey]

This change moves the ValueAccessors down into the Tree class instead of creating them in the Grid. Although we don't take advantage of this in the core library, this offers greater flexibility in allowing custom Tree implementations to define their own ValueAccessors rather than having to use the standard one.

[Idclip]

Whilst this looks good and the justification for the change makes sense, are we still trying to avoid introducing new methods to the tree? For example, wouldn't the advertised way of creating accessors not simply be ValueAccessor<T> acc(tree) or typename TreeT::Accessor acc(tree);

[danrbailey]

Whilst this looks good and the justification for the change makes sense, are we still trying to avoid introducing new methods to the tree? For example, wouldn't the advertised way of creating accessors not simply be ValueAccessor<T> acc(tree) or typename TreeT::Accessor acc(tree);

Yes and it's a fair question. In the broad sense, the methods that I think we should primarily target are those that recurse throughout the full tree hierarchy and that add significant cost to readability, parsing or instantiation. I don't think these convenience methods that live only on the tree are nearly as problematic when considered under that criteria and the trade-off is that creating accessors from a tree becomes much more unintuitive with these new methods I feel.