Add GPU offloadable SparseMatrixStorage and read-only SparseMatrixView.

[wdeconinck]

This is an alternative proposal to #241 , keeping its idea of using atlas::array::Array, but aiming to be more generic.
It decouples three things: 1) construction of a sparse matrix, 2) storage, 3) read-only access.

Instead of recreating a different atlas::linalg::SparseMatrix class, we have a SparseMatrixStorage class that can be constructed using various means of host-data.

• copy or move from eckit::linalg::SparseMatrix
• copy or move from Eigen::SparseMatrix
• copy from SparseMatrixView (see further).

The SparseMatrixStorage class holds three GPU-offloadable atlas::array::Array types to hold the sparse matrix data.
Since the atlas::array::Array types can hold any data type we can represent any precision SparseMatrix now, both for indices and values. Note that in order to support complex data type we need to extend atlas::array::Array to handle complex types (nudge @odlomax ).
When the SparseMatrixStorage is move-constructed from e.g. eckit::linalg::SparseMatrix or Eigen::SparseMatrix,
the Arrays will wrap these matrices in its host_data, and the GPU data will be owned.

The sparse_matrix_multiply API is refactored to take a templated SparseMatrixView<Value,Index> which provides a read-only access to either the host_data or device_data of the SparseMatrixStorage or other Sparse matrix formats.
It basically holds pointers. When these are device pointers, it is a device-view, and when they are host pointers it is a host-view.

The Interpolation classes and Caches have been adapted to hold the SparseMatrixStorage. @pmaciel , this may need an update on how you extract the eckit::linalg::SparseMatrix.
See here: https://github.com/ecmwf/atlas/compare/feature/sparse_storage_with_view?expand=1#diff-c5fa3d45217f3c703440ca5f193220d4b31fca9014d718a5f3a34971c1e2883fR109-R111

[l90lpa]

Hi @wdeconinck, your alternative looks great. Can I assume that the code isn't going to change much from this and thus start rebasing my other work on this?

[wdeconinck]

Hi @wdeconinck, your alternative looks great. Can I assume that the code isn't going to change much from this and thus start rebasing my other work on this?

I think that is safe to assume.

[l90lpa]

I think that is safe to assume.

Great, I've rebased #246 onto this branch.