Create NIXL wheel with CUObject Dependency for S3 RDMA (#1971)

## What?
Enable RDMA support in the S3 Object plugin for CUDA 13 Python wheels by
building them with cuObject Client support.

This PR:
- Parameterizes the `wheel_base` Docker stage: the PyPA manylinux base
image is now passed as `MANYLINUX_IMAGE`/`MANYLINUX_IMAGE_TAG` instead
of being hardcoded, so either can be overridden independently (e.g. to
mirror to Artifactory).
- Bumps the NGC CUDA source image from 13.0.1 to 13.2.1-devel-ubi8 — the
minimum release that provides `cuobjclient-13.2.pc`.
- Extracts `cuobjclient*.pc` from the CUDA stage and copies them into
`/usr/lib64/pkgconfig/` in the manylinux build environment so meson
auto-detects and links the OBJ plugin against `libcuobjclient.so.1`.
- Verifies that `libplugin_OBJ.so` carries a `libcuobjclient.so.1`
DT_NEEDED entry for CUDA 13 builds.
- Keeps `libcuobjclient.so.1` external to the wheel via an auditwheel
exclusion — the target system must supply the matching CUDA runtime
package.
- Updates both PR CI and nightly/release wheel pipelines to pass the new
manylinux image parameters and enables a cached `wheel_base` image for
the nightly, matching the PR CI approach.
- Switches the nightly from the internal combined base image to the same
public NGC ubi8 source used by the PR CI, so both environments are
identical.

CUDA 12 wheel builds are unaffected: no `cuobjclient*.pc` files are
present in the build environment, so meson's auto-detection produces the
same result as before.

## Why?
The existing wheel build images did not provide cuObject Client. Because
meson's `cuobjclient` option defaults to `auto`, CUDA 13 wheels could
build successfully while silently excluding the accelerated S3
implementations, leaving the S3 Object plugin without RDMA support.

CUDA 13.2's UBI8 development image provides the required cuObject
headers, libraries, and pkg-config metadata. Copying the `.pc` files
into the manylinux build environment ensures meson finds and links the
accelerated implementation, while auditwheel keeps the runtime library
out of the distributed wheel.

## How?
The manylinux build uses two separate stages:
1. A pinned NGC CUDA devel image
(`nvcr.io/nvidia/cuda:13.2.1-devel-ubi8`) supplies the CUDA toolkit and
stages `cuobjclient*.pc` into `/opt/nixl-cuda-pkgconfig/`.
2. A pinned PyPA manylinux image (`quay.io/pypa/manylinux_2_28`)
provides the wheel-compatible build environment.
3. Both the CUDA toolkit and the cuObject pkg-config files are copied
into the manylinux stage; `/usr/lib64/pkgconfig` is added to
`PKG_CONFIG_PATH`.
4. Meson auto-detects cuobjclient from `PKG_CONFIG_PATH` (no explicit
`-Dcuobjclient` flag needed).
5. A `readelf` check verifies that `libplugin_OBJ.so` carries
`libcuobjclient.so.1` as a DT_NEEDED entry for CUDA 13 builds.
6. `auditwheel repair` excludes `libcuobjclient*`, so the target system
must provide the matching CUDA runtime package.

The Jenkins PR and nightly matrices use `BASE_IMAGE`/`BASE_TAG` for the
CUDA source image and the new `MANYLINUX_IMAGE`/`MANYLINUX_IMAGE_TAG`
for the manylinux base, with separate cached `wheel_base` images per
CUDA variant to keep CI and published-wheel builds consistent.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **Chores**
- Updated nightly and matrix wheel builds to support CUDA 13.2 and CUDA
12 variants.
  - Switched nightly CUDA builds to NVIDIA CUDA NGC base images.
- Refreshed PyPA manylinux build images with configurable image and tag
settings.
- Updated container build defaults and caching for CUDA-specific wheel
images.
  - Added configurable PyTorch version support for wheel builds.
  - Improved CUDA library detection across supported versions.
- Enhanced CUDA 13 build validation and excluded additional client
libraries from repaired wheel bundles.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Adit Ranadive <aranadive@nvidia.com>