Consider statically linking the CUDA runtime

[vyasr]

Currently RAPIDS libraries support static linkage to cudart via a CMake flag CUDA_STATIC_RUNTIME. This flag is leveraged by wheel builds and by the Spark-RAPIDS JNI (specifically for cudf), but it is not the default. We would like to consider changing that. Using static libcudart has a few advantages:

• It aligns with the nvcc default.
• It aligns with recommendations from the CUDA programming guide. This lists multiple advantages including
  • It allows multiple CUDA runtimes to exist in the same process space. This is particularly valuable for RAPIDS in the context of packages like wheels where users could install wheels built against different CUDA runtimes, but can also be useful in other contexts.
  • Reduces the likelihood of compatibility issues
• Since it is nvcc's default behavior, that default has translated to conda-forge
• It overcomes some known performance issues with using the dynamic libcudart.so
• It would allow newer features to be used on user systems with older runtimes (newer drivers may still be required).

Given that cudart is small, the typical size concerns around static linking aren't concerning. However, the CUDA libraries (such as the math libraries like cuBLAS) are large, so we don't typically want to statically link those. Furthermore, static linking has the potential to open us up to issues around weak linking and CUDA kernels in the case of header-only libraries (i.e. anything using thrust, or raft). Therefore, before we can move to building statically by default, we should ensure that our libraries are safe to build that way by marking all kernels as static.

[vyasr]

As part of this work, we should also look into migrating from using an option CUDA_STATIC_RUNTIME across RAPIDS to instead using the built-in CMAKE_CUDA_RUNTIME_LIBRARY variable. cf. rapidsai/cudf#7888