Only zip c_stdlib_version with compilers for CUDA

[mbargull]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

There's no need to put the c_stdlib_version (and related keys) into the compiler-version zip key.
This tight coupling is only needed for the CUDA stuff.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

Fine by me, though I'd like to see it tested (like #5607; instructions therein) against some relevant feedstocks, e.g. https://github.com/conda-forge/ucx-split-feedstock.

[h-vetinari]

I'd like to see it tested (like #5607; instructions therein) against some relevant feedstocks, e.g. https://github.com/conda-forge/ucx-split-feedstock.

I did this now (both with and without conda-forge/conda-smithy#1889), and ucx-split, cupy, abseil-cpp, numpy all worked fine.

It's important to note that we cannot remove (from #5607)

conda-forge-pinning-feedstock/recipe/migrations/cuda120.yaml

Lines 93 to 94 in e29dc0a

	c_stdlib_version: # [linux and os.environ.get("CF_CUDA_ENABLED", "False") == "True"]
	- 2.17 # [linux and os.environ.get("CF_CUDA_ENABLED", "False") == "True"]

as the CUDA 12 builds still need that for the zip to work (though the effect is somewhat surprising - not an error, but the CUDA 12 builds simply getting dropped); I experienced that because

conda-smithy rerender --no-check-uptodate -e conda_forge_pinning.yaml

ends up not pulling in the newest migrator versions, and so this happened for ucx-split & cupy.

[mbargull]

FYI, AFAICT, there's only one feedstock for which the new cdt_name zipping would caused issues; I've address that in the feedstock at conda-forge/libusb-feedstock#22 .
(And we only needed to add c_stdlib_version there without any of the compiler versions due to this PR, of course.)