[WIP] Use gcc-toolset to build libcuvs for portability across libstdc++.so minor versions

[mythrocks]

Fixes #1248.
Depends on #1296.

This commit adds scripts to use gcc-toolset to build libcuvs (and librmm.so, libcuvs_c.so, etc.), so that the libraries are immune to minor ABI differences in libstdc++.so between the build host and the deployment hosts.

Prior to this commit, the minor ABI differences would manifest as follows:

$ git:(branch-25.10) ldd ./libcuvs.so                                                                                                          
./libcuvs.so: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by ./libcuvs.so)
        linux-vdso.so.1 (0x00007ef0ff6a1000)
        libnccl.so.2 => /home/mithunr/workspace/dev/cuvs/5/cpp/build/consolidated/./libnccl.so.2 (0x00007ef0a1000000)
         ...

With this change, the libraries should be portable across Linux distros, without also having to ship libstdc++ (as is done with the Conda-based releases).

Libraries built this way should be shippable via tarballs or packaged inside a fat jar.

Rather than have the gcc-toolset installed on the host machine, this commit introduces a new Dockerfile with the requisite packages used for building the portable libraries.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[mythrocks]

Tagging @jameslamb for his expertise. (Thank you for explaining the CI end of this to me.)

It looks like the CI scripts already use a pre-built container that covers a fair bit of what we have here.

Per @jameslamb, we should be able to reuse the CI docker container, and use the gcc-toolset-14 there to build the Java artifacts, and store them in Github's artifact storage.

We'll do a fresh draft PR that leverages the changes here to try that approach.

cc @cjnolet, @mmccarty.

[jameslamb]

Per @jameslamb, we should be able to reuse the CI docker container, and use the gcc-toolset-14 there to build the Java artifacts, and store them in Github's artifact storage.

Specifically, I think we can use the rapidsai/ci-wheel images which are based on Rocky Linux 8 and already use gcc-toolset-14: https://github.com/rapidsai/ci-imgs/blob/8a2f191c7605297ac0018307ffce9e1d0a2ade7b/ci-wheel.Dockerfile#L157

Those come with most of what's already needed, and by definition support the same range of GLIBC versions (and therefore Linux distributions) that the rest of RAPIDS does.

[mythrocks]

At this point, #1296 and #1264 are intertwined and co-dependent. I've moved these changes to #1296.

Closing, in favour of #1296.