Rust: Add nvtx-sys tools feature exposing the tools/injection ABI

[mbrobbel]

What

Adds a default-off tools feature to nvtx-sys that extends the existing bindgen allowlist with the NVTX tools/injection ABI from nvtxDetail/nvtxTypes.h:

• The callback-subscription types: NvtxExportTableCallbacks, NvtxExportTableVersionInfo, NvtxExportTableID, NvtxCallbackModule, all six NvtxCallbackId* enums, NvtxGetExportTableFunc_t, NvtxInitializeInjectionNvtxFunc_t, NvtxFunctionPointer, and NvtxFunctionTable.
• The function-table slot signatures (*_impl_fntype / *_fakeimpl_fntype) and the dependency-free fake types they reference (nvtx_CUdevice, nvtx_cl_*, ...), so tools cast slots to header-defined signatures instead of hand-maintained ones.
• The injection result codes (NVTX_SUCCESS, NVTX_FAIL, NVTX_ERR_*).

Why

Rust tools (injection libraries) currently have to run their own bindgen pipeline against the NVTX headers to get these types. Since nvtx-sys already generates bindings from the in-repo headers, exposing the tools ABI behind an opt-in feature lets tools depend on nvtx-sys directly.

This is the first of a series: follow-ups add subscriber support to the nvtx crate on top of this feature.

Notes

• With tools disabled, the generated bindings are byte-identical to before (verified by diffing generated bindings.rs); with it enabled they are a strict superset.
• The wrapper already parses nvtxTypes.h (it is included even under NVTX_NO_IMPL), so this only changes the allowlist/blocklist: the .*fntype.* blocklist now applies only when tools is off.

Verification

• check.sh profiles pass: fmt, check/clippy -Dwarnings and tests for --all-features, --no-default-features (± alloc), MSRV 1.77, and the thumbv7em-none-eabi no-default check; plus --features tools alone and tools,cuda,cuda_runtime.

🤖 Generated with Claude Code

[evanramos-nvidia]

We will need to see a concrete use case for this before we consider merging it.

Also, please see CONTRIBUTING.md.

[mbrobbel]

We will need to see a concrete use case for this before we consider merging it.

• Consume NVTX ranges rapidsai/quent#76

[willkill07]

This seems sensible to me. Exposition within the nvtx-sys crate should be viewed as safe in the general case.

We can be more critical of the end-user interface which builds upon it.

[9prady9]

merge ?