Replace per-capability libdevice bitcode with unified libdevice.10.bc

[alexreinking]

Summary

• Halide has vendored NVIDIA's per-architecture libdevice bitcode (libdevice.compute_{20,30,35}.10.bc) since its original CUDA/PTX backend landed circa 2013. NVIDIA itself dropped this per-capability split in CUDA 9.0 (2017) in favor of a single, architecture-generic libdevice.10.bc.
• The capability-based selection logic in LLVM_Runtime_Linker.cpp was never extended past sm_50, so every newer capability Halide supports (sm_61, sm_70, sm_75, sm_80, sm_86) silently fell through to libdevice.compute_20.10.bc — a Fermi-era (2010) file — regardless of the actual target GPU.
• This replaces the three vendored files with a single libdevice.10.bc (sourced from CUDA Toolkit 11.6) and simplifies Makefile, src/runtime/CMakeLists.txt, and src/LLVM_Runtime_Linker.cpp accordingly: one initmod, no capability-based selection table to keep in sync as NVIDIA adds compute capabilities.
• Adds src/runtime/nvidia_libdevice_bitcode/README.md documenting what the file is, how to refresh it, and the governing NVIDIA CUDA Toolkit EULA.

Fixes #9225

Test plan

• Configured and built libHalide from scratch (Ninja, LLVM 22, NVPTX enabled) with these changes; links clean.
• Compiled a small sin/sqrt GPU pipeline to PTX for sm_35, sm_61, and sm_86 targets — all succeed.
• Confirmed the sm_61 output now calls into the new libdevice (__nv_sinf, __internal_trig_reduction_slowpath, __nv_fmul_rn), where previously it would have silently linked the Fermi-era compute_20 file instead.