Closes #348.

This design addresses some problems we've had in the past when modeling sparse data where our objects were not flexible nor composable enough, which led to APIs which were hard to maintain and state which was hard to track.

This design starts by decomposing sparse formats into two components which are utlimately combined to compose the full sparse object:

1. a structural component manages the sparsity of the object , indexing, and data-specific metadata, such as total number of rows and columns.
2. a valued or matrix component combines with a structure and manages the nonzero elements.

Note that this design also affords the ability to model a sparse tensor in the future, as a new format tensor could allow for composing multiple structural and multiple valued components. This could enable our algorithms to support things decompositions of higher ordered structures and/or associated values.

In addition to being flexible and composable, this design also needs to satisfy a couple different levels of immutability:

1. Read-only: immutable structure, immutable nonzero elements
2. Fixed-sparsity and value-mutable: immutable structure, mutable nonzero elements
3. Mutable-sparsity and value-mutable: mutable structure, mutable nonzero elements

Two concepts introduced in this design are pretty core to the 3 states above:

1. structure-preserving formats are views and require the sparsity to be known at creation time. The actual structural components may or may not be mutable.
2. structure-owning formats house owning containers and don't require the sparsity to be known at creation time and provide a way to initialize() the sparsity once it is known. These formats will have mutable structure and nonzero elements.

Both the structure and matrix formats can be structure-preserving or structure-owning. While this PR only includes csr_matrix and coo_matrix (I'm considering dropping the r from csr since it doesn't really matter if it's csr or csc), the design will further allow for other formats, such as dcsr and bcsr, in the future.

1. csr_matrix_view - this is a structure-preserving matrix view. Sparsity must be known up front and the underlying arrays may or may not be const.
2. csr_matrix - this can be structure-owning or structure-preserving depending on whether its underlying structural component is structure-preserving (view) or structure-owning. Calling view() on this object produces the csr_matrix_view above.
3. coo_matrix_view - this is a structure-preserving matrix view. Sparsity must be known up front and the underlying arrays may or may not be const.
4. coo_matrix - this can be structure-owning or structure-preserving depending on whether its underlying structural component is structure-preserving (view) or structure-owning. Calling view() on this object produces the csr_matrix_view above.

Similar to mdarray and mdspan, a bunch of factory functions are provided in raft/core/device_sparse_matrix.hpp to ease the construction process for users. The owning matrix types can be constructed either to own the underlying structure or a view of the structure.

These new formats will allow us to model our sparse APIs so they are much more concise- a function can explicitly require a structure-owning matrix, which is a signal to the user that the function itself will compute the sparsity and at least fill in the initial structure. This will allow us to continue to provide an API which is easier to use, and ultimately feels more like our dense API, while still considering the design differences in sparse computations.

I also want to thank @divyegala for his help making the template metaprogramming layer flexible, reusable, and generally pleasant to use.

• more comprehensive googletests
• split into different files (types, compressed, coordinate, etc...)
• add host APIs