Building `cuda.bindings` in parallel might fail non-deterministically

[leofang]

Our new CI (#267) immediately exposes a longstanding, widely known setuptools/distutils issue when PARALLEL_LEVEL is set, xref:

• https://github.com/NVIDIA/cuda-python/actions/runs/12192916020/job/34014323275#step:4:2187

    D:\a\cuda-python\cuda-python\cuda_bindings\cuda\bindings\_bindings\loader.cpp : fatal error C1083: Cannot open compiler generated file: 'D:\a\cuda-python\cuda-python\cuda_bindings\build\temp.win-amd64-cpython-310\Release\cuda\bindings\_bindings\loader.obj': Permission denied

• [BUG] setuptools does not protect against race conditions on parallel builds pypa/setuptools#3119
• [BUG] Pararell builds result in different module content pypa/setuptools#3942
• Debug build on Windows fails without -j1 pypa/setuptools#2442
• Unable to build in parallel with Python 3 scipy/scipy#7112

[leofang]

tl;dr for the above threads is: The way that we build/link the same .c/.cpp file to multiple shared extension modules, i.e.,

cuda-python/cuda_bindings/setup.py

Lines 267 to 268 in 60f9362

	# private
	["cuda/bindings/_bindings/*.pyx", "cuda/bindings/_bindings/loader.cpp"],

is the root cause, as it triggers setuptools's race condition (which is a bug that would unlikely be fixed).

[leofang]

Bumping this to P0 as it now shows up in virtually every single (build) CI runs. @vzhurba01 please prioritize for fixing issues caught by the CI. Thanks!

[leofang]

Bumping this to P0 as it now shows up in virtually every single (build) CI runs.

I notice the situation gets worse after CI 2.0 was merged. Now when we rerun the failed jobs, not only the failed Windows build jobs are rerun, but also all downstream (test/doc) jobs, because as noted earlier there's no way in GHA to declare dependency on specific matrix elements of a job, only on the whole job.