Add VAAPI + Intel QSV hardware encoders

[crippledgeek]

Why

mediaforge currently builds NVENC (NVIDIA) + AMF (AMD) HW encoders but no VAAPI and no QSV. That's fine on NVIDIA-only hosts (the dev box is a GTX 1080 — VAAPI encode is unsupported there and QSV needs Intel HW), but mediaforge serves other users: Intel iGPU / Arc and AMD users need VAAPI; Intel users want QSV. Adding them makes the tool's HW-encode coverage complete.

What it takes (from feasibility research, 2026-06-04)

VAAPI (Intel + AMD on Linux):

• New recipes: libdrm (meson) + libva (meson, depends on libdrm). Permissive (MIT) — no GPL/nonfree gating. Linux-only.
• FFmpeg autodetects VAAPI when libva/libva-drm/libdrm are in the prefix (suppressed by --disable-vaapi). Yields h264_vaapi, hevc_vaapi, av1_vaapi, vp9_vaapi, mjpeg_vaapi.

QSV (Intel only; runs on top of VAAPI on Linux):

• New recipe: oneVPL / libvpl (cmake, static). FFmpeg --enable-libvpl (needs vpl ≥ 2.6). Yields h264_qsv, hevc_qsv, av1_qsv, etc.

Key design decision — static handling

VAAPI/QSV dlopen the GPU driver at runtime, so a static FFmpeg with VAAPI is not self-contained: the target still needs libva.so + a VA driver (iHD / Mesa). The canonical approach (BtbN/FFmpeg-Builds) is the gen-implib pattern: build libva shared, generate an import-stub .a, delete the .so, add -ldl to the .pc — the binary then uses VAAPI where a host driver exists and skips it otherwise. Need to decide: gen-implib stub vs. document a runtime libva dependency.

Acceptance

• libdrm + libva (+ oneVPL) recipes build static-clean; ordered before ffmpeg in _order.conf.
• ffmpeg -encoders shows *_vaapi (+ *_qsv if QSV included) on a build host with the libs.
• Verified on actual Intel/AMD hardware (CI or a real Intel/AMD box) — the dev NVIDIA box can't validate runtime.
• Docs note the runtime VA-driver requirement.

Follow-up to the codec-coverage work merged in #8.