Add a CUDA JLL for actually loading the runtime libraries.

[maleadt]

This is an experimental JLL, working my way towards actually using JLLs to load the CUDA runtime libraries instead of doing everything ourselves in CUDA.jl. It uses the cuda platform tag to determine which CUDA toolkit to load (based on driver compatibility and toolkit availability). That tag can then used by dependent JLLs, like CUDNN, to determine which library to load.

Note that I didn't use a comparison strategy for determining which toolkit artifact to load. Instead, I'm using plain equality, but providing the list of available toolkits to augment_platform! instead (essentially embedding that in the generated JLL). This results in the platform tag containing the actual toolkit loaded, instead of the host's compatibility, which should make it easier for dependent JLLs to determine which artifact they can load.

I'm not sure about the comparison strategy for dependent packages, so @giordano if you could review that (given how you've been looking into this recently).

The other big change that this JLL will result in, is that using CUDA_Runtime_JLL will eagerly download and load the CUDA runtime libraries (because we lack the flexibility of lazy-downloading or lazy-loading with JLLs right now, even with lazy artifacts). So packages depending on the CUDA stack will need to use Preferences to avoid loading CUDA if it isn't to be used. That's a departure from how things work right now.

[maleadt]

I'll merge this already so that I can experiment with the generated artifacts, but feel free to comment/review on here after that.

[giordano]

My current understanding of the comparison strategy is encapsulated in JuliaPackaging/BinaryBuilderBase.jl#233, and what you did here matches what I did there, so I'd say it's ok. But I definitely don't understand all the details yet 😁