Make the Windows ROCm load path work and fix has_imma on ROCm

[IxMxAMAR]

Two things on the Windows + ROCm path, both of which make a broken install look like a bitsandbytes bug.

Loading the library. On CPython 3.8+ the Windows loader uses LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, which does not include PATH and does not include the directory of the DLL being loaded. When the ROCm runtime isn't already resident in the process, an extension sitting next to a perfectly good ROCm install still can't resolve amdhip64_*.dll, and ctypes reports it as:

FileNotFoundError: Could not find module '...\libbitsandbytes_rocm72.dll'
(or one of its dependencies). Try using the full path with constructor syntax.

That names the wrong file, so it reads as "bitsandbytes is broken" when the runtime just isn't resolvable. Two changes: register the usual runtime directories with os.add_dll_directory before LoadLibrary, and classify the error as a missing dependency so the advice points at the runtime instead. The handles are kept alive in a module-level list, because closing one removes the directory again.

Worth being precise about the scope, because I initially overstated it. If torch's ROCm build is imported before bitsandbytes, amdhip64.dll is already loaded in the process and a plain LoadLibrary resolves the dependency regardless of search path. I checked that directly: with ROCm absent from PATH and no add_dll_directory, the load still succeeds once torch is up. So the ordinary import order was never affected, and this is not "Windows ROCm cannot load at all". The failure needs a process where the runtime isn't resident yet, which is what the reproduction below does. The registration makes that case work and, more usefully, makes the error message stop blaming the wrong file.

Reading the capability. has_imma compared highest_compute_capability >= (7, 5). On ROCm that means gfx906 reports 9.0 and gets treated as having MFMA, which it doesn't, and the int8 kernels gate on this. It's decided from the gfx target now, with gfx900/906/90c excluded. get_rocm_gpu_arch reads gcnArchName off torch.cuda.get_device_properties instead of parsing rocminfo, and returns "unknown" rather than raising when there's no HIP. Also small: BNB_ROCM_VERSION only accepted the compact form (72), so 7.2 was rejected as garbage; both are accepted.

Verified on an RX 9070 XT (gfx1201, ROCm 7.2, clang 23, MSVC 18), Windows 11:

• Reproduced the load failure for real rather than only asserting on a string: in a bare interpreter with torch not imported and ROCm stripped off PATH, ct.cdll.LoadLibrary on the built extension fails with FileNotFoundError and winerror=None, then loads once os.add_dll_directory is given the ROCm bin.
• That reproduction is what caught a bug in my first version of this patch. I matched [WinError 126] and "The specified module could not be found", and the error ctypes actually raises contains neither. The matcher covers both forms now and there's a test carrying the verbatim message.
• 19 tests in tests/test_cextension_errors.py, and test_linear8bitlt.py gives 39 passed / 16 skipped, which is the path has_imma gates.

Not verified: the CUDA wording of the hint, and installs that put ROCm somewhere outside ROCM_PATH / HIP_PATH / ROCM_HOME / CONDA_PREFIX / torch's lib / PATH. The registration scans those and skips directories without amdhip64*.dll, so an unusual layout falls back to the current behaviour instead of breaking. There's no GPU-arch-specific testing either: this was all on one gfx1201 card, and the gfx906/gfx900 has_imma expectations are from the target names, not from hardware.