hip-python-as-cuda: add the cuda-python 12+ cuda.bindings module layout

Start by inspecting the existing cuda.cuda and cuda.cudart modules and their aliasing approach. Add the cuda.bindings package with driver, runtime, and nvrtc submodules, then verify the documented imports and supported managed-memory and graph calls against the hip-python wheel. Also check the PyPI, Test PyPI, or source-build path so the compatibility package is installable alongside hip-python.

The CUDA interoperability package currently mirrors the legacy cuda-python layout: from cuda import cuda, from cuda import cudart, from cuda import nvrtc. cuda-python 12.0 restructured its bindings into cuda.bindings.driver, cuda.bindings.runtime, and cuda.bindings.nvrtc, and downstream consumers have moved to that layout.

Concrete consumer: PyTorch imports from cuda.bindings import driver, runtime in several places (torch/cuda/_utils.py, torch/cuda/graphs.py for graph introspection and debug-dot dumps, torch/cuda/memory.py for a managed-memory allocator, torch/cuda/_graph_annotations.py). On ROCm builds, PyTorch currently reports cuda.bindings as unavailable, because NVIDIA's package installs and imports fine on a ROCm box but fails at the first call. If hip-python-as-cuda provided a working cuda.bindings layout, PyTorch could switch that platform gate to a functional probe and light these features up on ROCm.

What would work immediately through such a layout, verified with the hip-python 7.2.2 wheel against a HIP 7.15 runtime on gfx950: managed memory (hipMallocManaged, hipMemAdvise, hipFree, which is all PyTorch's UVM allocator needs), graph topology introspection (hipGraphGetNodes/GetEdges/NodeGetType/KernelNodeGetParams), and hipGraphDebugDotPrint. Some PyTorch features additionally need HIP APIs that do not exist yet (hipGraphNodeGetToolsId, hipGraphGetId/hipGraphExecGetId, hipFuncGetName); those are separate HIP runtime asks and not blockers for the layout itself.

Asks:

1. Add a cuda.bindings package (with driver, runtime, nvrtc submodules) to hip-python-as-cuda, using the same aliasing approach as the existing cuda.cuda/cuda.cudart modules. The call/return convention ((err, *outs) tuples) already matches cuda-python, so this is primarily a module-layout addition.
2. Publish hip-python-as-cuda wheels to PyPI alongside hip-python, or document the Test PyPI/source-build path prominently; the layout only helps consumers when the package is installable the way cuda-python is.

This issue was drafted with the help of an AI assistant (Claude); the compatibility claims were verified by hand against the hip-python 7.2.2 wheel.