RAFT is getting a little more attention and I'm just updating a few things in the docs to make them look more polished.

Authors:
  - Corey J. Nolet (https://github.com/cjnolet)

Approvers:
  - Ben Frederickson (https://github.com/benfred)

URL: rapidsai#1339

Refactor of `ivf_flat::index` to split the cluster data in separate buffers
- Addressing rapidsai#1170.
- Following rapidsai#1249 in the index structure implementation.
- Adding serialization API with stream and filename overloads
- Moving `raft::spatial::knn::ivf_flat` namespace to `raft::neighbors::ivf_flat`

Authors:
  - Micka (https://github.com/lowener)
  - Corey J. Nolet (https://github.com/cjnolet)
  - Artem M. Chirkin (https://github.com/achirkin)

Approvers:
  - Tamas Bela Feher (https://github.com/tfeher)
  - AJ Schmidt (https://github.com/ajschmidt8)
  - Artem M. Chirkin (https://github.com/achirkin)

URL: rapidsai#1271

cc @robertmaynard @MatthiasKohl

Authors:
  - Corey J. Nolet (https://github.com/cjnolet)

Approvers:
  - Robert Maynard (https://github.com/robertmaynard)

URL: rapidsai#1341

Closes rapidsai#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. 

- [x] more comprehensive googletests
- [x] split into different files (types, compressed, coordinate, etc...)
- [x] add host APIs

Authors:
  - Corey J. Nolet (https://github.com/cjnolet)

Approvers:
  - Divye Gala (https://github.com/divyegala)

URL: rapidsai#1279

Update and standardize IVF indexes API + edits on specializations

Authors:
  - Victor Lafargue (https://github.com/viclafargue)
  - Corey J. Nolet (https://github.com/cjnolet)

Approvers:
  - Corey J. Nolet (https://github.com/cjnolet)
  - Artem M. Chirkin (https://github.com/achirkin)

URL: rapidsai#1328

Authors:
  - Victor Lafargue (https://github.com/viclafargue)

Approvers:
  - Corey J. Nolet (https://github.com/cjnolet)

URL: rapidsai#1345

Add Python wrappers to IVF-Flat.

closes rapidsai#1139 

It also adds a C++ interface to raft_runtime, that is called from Cython wrappers. The corresponding specializations are defined, but not used elsewhere (see rapidsai#1238).

Authors:
  - Tamas Bela Feher (https://github.com/tfeher)
  - Victor Lafargue (https://github.com/viclafargue)
  - Corey J. Nolet (https://github.com/cjnolet)
  - Divye Gala (https://github.com/divyegala)

Approvers:
  - Corey J. Nolet (https://github.com/cjnolet)

URL: rapidsai#1316

I switched the doxygen documentation from `doxygenfunction` to `doxygengroup` because there was an issue resolving the `deserialize` methods on both ivf-flat and ivf-pq.

Authors:
  - Micka (https://github.com/lowener)

Approvers:
  - Corey J. Nolet (https://github.com/cjnolet)

URL: rapidsai#1347

… for wheels (rapidsai#1348)

Using MANIFEST.in currently runs into a pretty nasty scikit-build bug (scikit-build/scikit-build#886) that results in any file included by the manifest being copied from the install tree back into the source tree whenever an in place build occurs after an install, overwriting any local changes. We need an alternative approach to ensure that all necessary files are included in built packages. There are two types:
- sdists: scikit-build automatically generates a manifest during sdist generation if we don't provide one, and that manifest is reliably complete. It contains all files needed for a source build up to the raft C++ code (which has always been true and is something we can come back to improving later if desired).
- wheels: The autogenerated manifest is not used during wheel generation because the manifest generation hook is not invoked during wheel builds, so to include data in the wheels we must provide the `package_data` argument to `setup`. In this case we do not need to include CMake or pyx files because the result does not need to be possible to build from, it just needs pxd files for other packages to cimport if desired.

Authors:
  - Vyas Ramasubramani (https://github.com/vyasr)

Approvers:
  - Ben Frederickson (https://github.com/benfred)

URL: rapidsai#1348

This PR improves the ability to do dispatch based on compute architecture. It is a follow up to rapidsai#1142.

It has two goals: 

1. Make it easier to specify which compute architectures a kernel is compatible with / should be compiled for.
2. Make it easier to compile a kernel only for the architectures for which it is used (if it is unused, the kernel should be empty).

We have a specific use case in RAFT for this feature. For the L2 pairwise distance kernel we have a CUTLASS based implementation that works om SM80+ and a fallback kernel. Preferably, each kernel is only compiled for the architectures on which it is actually used.

Authors:
  - Allard Hendriksen (https://github.com/ahendriksen)
  - Corey J. Nolet (https://github.com/cjnolet)

Approvers:
  - Tamas Bela Feher (https://github.com/tfeher)
  - Corey J. Nolet (https://github.com/cjnolet)

URL: rapidsai#1335

Replace faiss bfKnn with code that leverages our pairwise_distance api and select_k api - by tiling over the inputs.

This lets us remove faiss as a dependency

Closes rapidsai#798 
Closes rapidsai#1159

Authors:
  - Ben Frederickson (https://github.com/benfred)
  - Corey J. Nolet (https://github.com/cjnolet)

Approvers:
  - Corey J. Nolet (https://github.com/cjnolet)
  - Ray Douglass (https://github.com/raydouglass)

URL: rapidsai#1202