Refactor to remove ndindex.

Okay, this is the re-implementation to remove the use of ndindex and exploit the capability of the SciPy `_RegularGridInterpolator` to perform N-d interploation. 

This requires massaging the data such that the dimensions to be interpolated occupy the lower dimensions e.g. given a 4-d (T, Z, Y, X) cube, and we wish to interpolate linearly over dimensions X and Y (note the order), then the cube must first  be transpose to (X, Y, T, Z), then interpolated over given the sample points, and then transposed back to its original dimensional order of (T, Z, Y, X).

Note that, if there are M sample points in the X dimension, and N sample points in the Y dimension, then a cross-product of sample points is calculated, resulting in a (M * N, ndim) array, which is then used by the `_RegularGridInterpolator` to perform the actual interpolation. Where `ndim` is the number of dimensions being interpolated over, so given our worked example ndim = 2.

The interpolation result must then be reshaped, as the `_RegularGridInterpolator` will return a (M x N, ...) result. So the M x N points must then be reshaped to give (M, N, ...).

One small caveat that caused no end of grief, is that the dtype of the sample points can influence the dtype of the interpolated result i.e. given the example above, if the cube data is float32, the X and Y point data is float32, but the sample point data is float64, then the interpolated result will be float64.

There are seven outstanding test failures. I'm assuming related to accuracy issues. I've not had the time to track down the root of the problem, but I inherited these from the original @pelson branch.

The `LinearInterpolator.points` method should be made private, but @cpelley will factor this into his PR.

One further extension to this PR is to remove the need to broadcast coordinate data payload up to the full dimensionality of the cube data payload. This would involve a major change to the current `LinearInterpolator` class, so I think it's wise to do that in a separate PR ... we still need to debate whether this is practical.