Add exact-name bitcode library lookup

[benhg]

Description

Addresses new design of #2200.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[rwgk]

@benhg, @leofang: I checked CUDA 12.0–13.3 and NVSHMEM cu12 wheels 3.6.5, 3.7.0, and 3.7.1. All actual bitcode filenames end in .bc, but NVSHMEM’s bitcode directory also contains .a archives, the host .so, and bootstrap/transport plugins. As written, find/locate_bitcode_lib_by_name() can return any of those by basename. Should the API require a .bc filename, or is generic exact-name lookup within the configured directory intentional? Would suffix validation be the right contract, or do we want content-level bitcode validation?

[benhg]

@benhg, @leofang: I checked CUDA 12.0–13.3 and NVSHMEM cu12 wheels 3.6.5, 3.7.0, and 3.7.1. All actual bitcode filenames end in .bc, but NVSHMEM’s bitcode directory also contains .a archives, the host .so, and bootstrap/transport plugins. As written, find/locate_bitcode_lib_by_name() can return any of those by basename. Should the API require a .bc filename, or is generic exact-name lookup within the configured directory intentional? Would suffix validation be the right contract, or do we want content-level bitcode validation?

I could go either way. The argument in favor of looser checking is we may have new formats (e.g. .bc.fatbin or .bc.gz or something), and could use the same function to support .ltoir. The argument against is more risk of bugs