Improve control point indexing

[SouthEndMusic]

The current status

There currently are 2 types of control point objects:

1. DefaultControlPoints, which is a thin wrapper around an Nin+1 dimensional array. This object can be indexed in the same way as the underlying array;
2. LocallyRefinedControlPoints, which is much less structured, and can only be indexed as a matrix of size (n_control_points, Nout).

This difference in indexing can lead to confusion and messy code (as is for instance already the case in SplineGrids.plot_basis!.

Apart from indexing there is also the function obtain, which yields an Nin+1 dimensional array for any control point object (which is not allocated but exists within the control points object).

To do

1. Should what is now called obtain actually be made methods of Base.collect? That seems sort of intuitive, although Base.collect I think often allocates a new array for the output. This requires some investigation into the precise intention of Base.collect. On the other hand, it would make intuitive sense to add a call to evaluate! for the control points when calling Base.collect, but that should not be part of obtain for more control and avoiding unnecessary calculations.
2. Should all control points objects have the same indexing behavior, i.e. as if it were an array of size (n_control_points, Nout)?

I think it makes most sense to have:

• Indexing for accessing all degrees of freedom, i.e. the active control points of each level, for all control point types as an (n_control_points, Nout) shaped array
• obtain used internally for obtaining the control point grid for spline grid evaluation
• Base.collect for obtaining a copy of the control point grid for spline grid evaluation with an internall call to evaluate! on the control points beforehand.
• A dedicated section in the docs for control point indexing