[BUILD] Packaging follow-ups: Ubuntu 22.04 compat, rpath audit, per-branch backends, vendor runtime deps

[shiptux]

Follow-up to #794/#796. Four concerns were raised about the deb/rpm packaging; each was verified against main and the built artifacts. Status and actions below. (I'll take this — please assign to @shiptux.)

1. Wheels built on Ubuntu 24.04 are unusable on 22.04 — confirmed

libtriton.so requires GLIBC_2.38 / GLIBCXX_3.4.32 (verified with strings); Ubuntu 22.04 ships glibc 2.35 / GLIBCXX 3.4.30. The deb's ${shlibs:Depends} does work — the built package declares libc6 (>= 2.38), libstdc++6 (>= 13.1), so 22.04 fails at install time, not at runtime.

• Add an ubuntu:22.04 matrix variant (DEB_BASE_IMAGE is already parameterized; the same-base two-stage build handles the py3.10 ABI automatically)
• Longer term: evaluate a manylinux-style wheel to cover multiple distros with one build

2. rpath / hardcoded paths — not reproduced on main (nvidia)

All shipped .so files have no RPATH/RUNPATH, DT_NEEDED lists only system libs, and patchelf has zero occurrences on main (repo grep + GitHub code search). The reported patch_elf hardcoding lives on vendor-backend branches, so this becomes relevant when packaging those backends.

• Re-verify on a current 0.6.0 wheel (adds libproton.so and instrumentation libs)
• Add an import triton smoke test to the assembler stages — CI is currently blind to the whole "installs fine, fails at import" class (covers both [TEST] check ci/cd #1 and [BUILD] [DOC] fix xpu download link #2)
• When packaging a vendor backend: audit its .so files for RPATH/hardcoded paths; patch to $ORIGIN-relative where needed

3. Backends live on separate branches — confirmed

Upstream has many per-backend branches (ascend_*, backend/enflame/*, feat/mthreads-*, ...). Packaging files exist only on main, so "add a matrix entry" is not enough for other backends.

• Per-backend packaging should be driven by backend-variant tags (0.6.0+mthreads3.6) — a tag push checks out the tagged branch; the current job-level + skip in the workflows is the placeholder to replace with a tag→backend mapping
• Packaging files need to be synced/cherry-picked to backend branches (or wait for branch consolidation)

4. Vendor runtime deps are huge and undeclared — confirmed for tsingmicro

python/setup_tools/setup_helper.py (tsingmicro section) pulls a full LLVM toolchain tarball plus tx8_deps and requires TX8_DEPS_ROOT at build time; nothing distinguishes build-time from runtime deps. Distro packages can't declare these as Requires/Depends (not in any repo), and bundling them explodes package size and CI disk.

• Decide a per-backend packageability policy: self-contained backends (nvidia/amd) get standard packages; vendor-dep backends get Recommends + documented manual install, or require a vendor apt/yum repo
• Note: the tsingmicro toolchain targets glibc 2.30 / GLIBCXX 3.4.28 (per its tarball name) — conflicts with a 24.04 build base; interacts with [TEST] check ci/cd #1