ENH: CPU implementation of SparseDiagonalMatrixTiled class

This MR depends on !21 (merged) and !24 (merged) which must be merged first.

The SparseDiagonalMatrixTiled class has been restructured to allow for separate CPU and GPU implementations.

• There is a single SPDT class definition in inc/SparseDiagonalMatrixTiled.h. The class has been adjusted so that it does not use the PIMPL idiom, but instead holds a reference to an opaque SPDT::Data instance.
• Platform agnostic logic is contained in src/SparseDiagonalMatrixTiled.cpp.
• CPU and GPU specific logic is contained in src/SparseDiagonalMatrixTiledCPU.cpp src/SparseDiagonalMatrixTiledGPU.cu, which also contain definitions of the SPDT::Data class - the GPU implementation uses thrust::device_vector to store the matrix data, and the CPU implementation uses std::vector.
• The implementation can be selected at compilation time simply by linking either SparseDiagonalMatrixTiledCPU.o or SparseDiagonalMatrixTiledGPU.o

Some changes have been made to the SPDT interface to remove coupling to CUDA device memory, and allow for a CPU implementation:

• The SPDT.get_element and SPDT.set_element functions have been removed. The only use of these functions was by the CostFxnPointCloudWarpField class, which has been adjusted so that the matrix data is created on the CPU, and then copied into the SPDT matrix via a call to the new SPDT.set_elements function. This change has resulted in a substantial speed-up of the initialisation logic in the CostFxnPointCloudWarpField class, and has allowed CPU-GPU synchronisation logic to be removed from the SPDT class.

• The SPDT.get_raw_pointer and SPDT.get_const_raw_pointer functions have been removed and replaced with SPDT.get_tile and SPDT.set_tile functions, which allow a client to read/write entire matrix tiles. This means that a copy must be made when reading/writing matrix data, but this doesn't seem to have a substantial effect on performance.

In order to allow the CPU SPDT implementation to be used with GPU code (e.g. cost functions for which we don't yet have CPU implementations), a few functions have been added in src/SparseDiagonalMatrixTiled_temporary_shim.cu - these functions simply copy between thrust::device_vector/thrust::host_vector and std::vector, and can be removed once we have a full CPU implementation.

This MR also adjusts the MMORF Makefile to allow for CPU and GPU executables to be installed alongside each other, and for binary files to live alongside each other in a local development environment:

• CPU object files are saved to build/CPU/
• GPU object files are saved to build/GPU/
• The CPU executable is saved to build/CPU/mmorf_cpu
• The GPU executable is saved to build/CPU/mmorf_cuda11.0 (when compiled against CUDA 11.0)
• Both mmorf_cpu and mmorf_cuda11.0 will be installed into $FSLDIR/bin/, along with a new Python script called $FSLDIR/bin/mmorf, will call $FSLDIR/bin/mmorf_cuda11.0 if a GPU is available, or will fall back to $FSLDIR/bin/mmorf_cpu otherwise.

The CPU/GPU versions of MMORF will be published as two separate conda packages which can be installed into the same environment:

• mmorf-cuda-11.0 provides $FSLDIR/bin/mmorf $FSLDIR/bin/mmorf_cuda11.0, and $FSLDIR/bin/tensor_average, although this may be removed/changed at some point.
• mmorf-cpu provides $FSLDIR/bin/mmorf_cpu