Make cuco a private dependency and leverage rapids-cmake

[vyasr]

After #2398 cuco is not actually part of libcugraph's public API and should not be required by consumers. Since it is already not being installed, this PR removes it from the public link interface of libcugraph. This PR also uses rapids-cmake to fetch cuco, ensuring that libcugraph remains in sync with the rest of RAPIDS.

There are a handful of tests that still rely on libcugraph::detail APIs that use cuco. To minimize the leakage of these dependencies, they are explicitly linked to cuco (rather than the current approach where they receive the cuco headers transitively from the libcugraph target).

[vyasr]

It looks like there are a handful of tests and test utilities that make use of cugraph detail APIs that use cuco. Is that expected? This looks like dependency leakage due to use of detail APIs outside of the package. I am investigating what a minimal solution would be for removing that dependency, perhaps simply compiling the necessary components into a small test utilities component inside cugraph similar to what cudf does. However, an ideal solution (which requires more cugraph expertise than I have) is finding a way to not use internal APIs outside of the main package.

CC @rlratzel @robertmaynard

[rlratzel]

cc @ChuckHastings

[vyasr]

From some offline discussions, we've decided that the current tests are useful in their current form. While they may be rewritten at a later date after some significant internal refactorings, for now we're just going to link them directly to cuco to enable the continued used of the detail APIs.

[vyasr]

I was surprised to find how many of the multi-GPU tests have a cuco dependency, but I think I've got them all now.

[ChuckHastings]

@gpucibot merge