Develop a consistent CMake strategy for supporting static library builds

[vyasr]

Currently we have two approaches to building static libraries. In cudf, we omit the library type in the add_library call and therefore implicitly defer selection to the value of BUILD_SHARED_LIBS. Conversely, in raft and projects derived from it (cuvs), we compile an object library first and then link those objects into separate shared and static libraries. The latter approach is perhaps a bit more flexible in principle since it allows building both libraries in the same build command, but our current implementations are such that they always build both artifacts, which tends to be undesirable in some scenarios where you really only require a dynamic or a static library but not both. The former approach is more immediately familiar to general CMake users since many libraries in the wild already employ that strategy by default since it is supported out of the box by CMake.

We should decide which of these approaches we prefer and either define some best practices or, if possible, write some helpers into rapids-cmake to clarify this. As our binary offerings become more complex and varied (see #33 and #45 in particular), we will want this flexibility so that we can consistently and easily build and ship exactly the binaries we want on different platforms.

[vyasr]

@robertmaynard what do you think makes the most sense to do here?