Add manylinux_2_28 wheel build alongside manylinux_2_34

[saurabh500]

Why

mssql-py-core wheels are repackaged into mssql-python, which ships a single manylinux_2_28 Linux wheel tag per arch. Today our build produces only glibc-2.34 / OpenSSL-3 binaries, so the .so embedded inside mssql-python's manylinux_2_28 wheel actually requires GLIBC_2.34 and libssl.so.3 — the tag is a lie and the wheel will not load on real glibc-2.28 hosts (RHEL 8, Ubuntu 20.04, Debian 11, Amazon Linux 2).

This PR adds a true manylinux_2_28 build path while keeping the existing manylinux_2_34 path, so we can hand mssql-python an ABI-honest .so for each deployment target.

Tag	Built in	Links to	Max GLIBC	For
manylinux_2_28_<arch>	AlmaLinux 8	libssl.so.1.1	2.28	RHEL 8, Ubuntu 20.04, Debian 11, Amazon Linux 2
manylinux_2_34_<arch>	AlmaLinux 9	libssl.so.3	2.34	RHEL 9+, Ubuntu 22.04+, Debian 12+

OpenSSL stays a runtime OS dependency in both flavors (auditwheel = "skip" preserved); the wheel never bundles or statically links libssl.

What changed

• New Dockerfiles containers/Dockerfile.PythonBuild.manylinux_2_28.{x64,arm64} mirroring the existing 2_34 ones, FROM the imported 2_28 ACR base.
• containers/build-python-images.sh / push-python-images.sh build and push both manylinux flavors (4 manylinux images + 2 musllinux = 6 total).
• scripts/build-python-wheels-in-container.sh reads MATURIN_COMPATIBILITY env and passes --compatibility to maturin so the wheel filename / WHEEL metadata carry the correct manylinux_2_<N>_<arch> tag. Previously fell back to the un-publishable linux_* tag because auditwheel = "skip" is set. Also runs cargo clean first so running both flavors against the same workspace in one job doesn't leak OpenSSL/glibc cache across flavors.
• scripts/build-wheels-docker-host.sh takes a MANYLINUX_FLAVOR arg (default 2_28), picks the right _rust image, and sets MATURIN_COMPATIBILITY. Fixed stale references to the non-_rust base images.
• .pipeline/templates/build-python-wheels-template.yml adds a manylinuxFlavor parameter (default 2_28); the published artifact name on Linux now includes the flavor (wheels_Linux_<arch>_manylinux_2_28, ..._manylinux_2_34) so the two invocations per arch don't collide.
• .pipeline/OneBranch/stages.yml and .pipeline/templates/validation-stages.yml call the wheel template twice per Linux x64/arm64 job (once per flavor).
• mssql-py-core/pyproject.toml comment + containers/PYTHON_WHEELS_README.md describe the dual-flavor strategy.

Verification

Built both Dockerfiles locally, ran the in-container wheel build through each, then inspected the produced wheels:

manylinux_2_28_x86_64.whl
  libssl.so.1.1  /  libcrypto.so.1.1   (OpenSSL 1.1)
  max GLIBC      2.28
  auditwheel show: 'constrains the platform tag to manylinux_2_28_x86_64'

manylinux_2_34_x86_64.whl
  libssl.so.3    /  libcrypto.so.3     (OpenSSL 3)
  max GLIBC      2.34
  auditwheel show: 'constrains the platform tag to manylinux_2_34_x86_64'

Cross-flavor cache contamination was reproduced and confirmed fixed by the new cargo clean step.

Follow-ups (out of scope for this PR)

• Build and push the new manylinux_2_28_*_rust images to ACR (./containers/build-python-images.sh && ./containers/push-python-images.sh) and mirror to GHCR via the existing sync.
• Point mssql-python's repackaging at wheels_Linux_<arch>_manylinux_2_28 for its 2_28 wheel (and ...manylinux_2_34 if/when they ship a 2_34 wheel as well).

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com