Revisit `cuda-bindings` branching strategy

Right now we have cuda-bindings 12.9.x maintained in the 12.9.x branch. This causes frictions for

• understanding the maintenance scope
  • it is not obvious at all that only .github/, ci/, cuda_bindings/, and cuda_python/ are maintained there
• tracking and backpoting fixes (https://github.com/NVIDIA/cuda-python/issues/965)
• maintaining CI infra (https://github.com/NVIDIA/cuda-python/issues/1058) and docs (https://github.com/NVIDIA/cuda-python/issues/809)
• releasing 12.x packages (https://github.com/NVIDIA/cuda-python/issues/1120)

We would like to lower the burden and the mental overhead on the team. Possible solutions include:

• Eliminate the backport needs by hosting two directories cuda_bindings_12/ and cuda_bindings_13/ on the main branch
• Generate the same binding code that have a bunch of macros that can be toggled at build time to target CUDA 12/13
• ...