Add QEMU system mode

[MementoRC]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated recipe".
• Recipe uses the v1 recipe.yaml format, or this PR explains the exceptional requirement for deprecated v0.
• License file is packaged (see the v1 example recipe for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

QEMU **11.0.3**, system-mode emulators only.

- Outputs split

  Three published blocks
    qemu-system-common           | Everything under share/ that isn't a binary or arch-specific firmware
    qemu-system-tools            | Host-side utilities independent of target CPU avoids re-shipping identical binaries per architecture.
    qemu-system-<arch> (fan-out) | qemu-system-<arch> binary Most users need one or two target architectures; a single fat package would force everyone to pull all three firmware sets (UEFI, SLOF, OpenSBI) even when only one target is used.
       - variants.yaml  drives the qemu-system-<arch>

- Scripts split (preference: subject to revision, in particular now that the recipe focusses on system)

  build.sh                       | Entry point. Dispatches to the Unix or Windows build function.
  helpers/feature_profiles.sh    | Pure functions: Separates configure-flag *policy* from build *mechanics*. Honestly, leftover from a richer prior flag matrix.
  helpers/build_install_qemu.sh  | configure/ninja/ninja install for Unix and Windows
  helpers/windows_workarounds.sh | Windows-only: pre-decompresses EDK2 firmware, builds the pyvenv + meson wrapper (next section), sed-patches build.ninja for tool-name suffixes and QAPI path breakage.

- The patch set

Selector blocks are mutually exclusive per platform (numbering highlights pathces removal to clean-up - not yet done at PR submission)

  0002-osx-attr-meson.build.patch                   | <attr/xattr.h> is Linux-only; macOS needs <sys/xattr.h>. | Upstreamable |
  0003-osx-block_file-posix.c.patch                 | IOMainPort - IOMasterPort IOKit call. *(SDK boundary requiring the older symbol not stated - maintainer to confirm.)* | Deliberate down-port |
  0004-osx-audio_coreaudio.m.patch                  | kAudioObjectPropertyElementMain - ...ElementMaster (6 sites), same SDK-compat pattern. | Deliberate down-port |
  0001-non-unix-add-console.patch                   | Adds -Wl,--subsystem,console,-e,mainCRTStartup link args. *(Why the base target needs console subsystem given the separate GUI <arch>w variant isn't explained - maintainer to confirm.)* | conda-forge-specific |
  0002-non-unix-configure-pyvenv.patch              | Resolves meson under pyvenv/Scripts with hardcoded .exe, not pyvenv/bin; adds CONDA-DEBUG logging. | conda-forge-specific; debug logging should drop before upstreaming |
  0003-non-unix-fix-MESONINTROSPECT.patch           | shlex.split() mangles Windows backslash paths in $MESONINTROSPECT; falls back to shutil.which('meson'). | Upstreamable |
  0006-non-unix-mkvenv-accept-system-packages.patch | Trusts canary executables, drops _is_system_package check (conda packages aren't in importlib.metadata), clear=False so the pre-built venv survives. | conda-forge-specific |
  0002-block-fix-missing-rwf-flags.patch            | RWF_DSYNC used unconditionally but absent from conda-forge's older pinned sysroot headers. | Upstreamable defensive guard |
  0003-system-fix-missing-clone-newcgroup.patch     | CLONE_NEWCGROUP missing from same sysroot; mirrors the existing CLONE_PIDFD guard in-file. | Upstreamable (matches accepted pattern) |

- The Windows meson bootstrap

  This is the ugliest part of the recipe (helpers/windows_workarounds.sh,
  setup_windows_pyvenv/patch_windows_build_ninja). Per the CI-confirmed comment
  block there: ninja invokes CreateProcess **directly** (no shell) on the first
  argument of a custom_target command. QEMU's meson build has a self-regeneration edge
  (REGENERATE_BUILD) that config-poison.h, among other custom_targets, depends on.
  On Windows, meson's own self-derived regeneration command uses the bare extensionless
  pyvenv/Scripts/meson path - independent of how configure resolved $meson
  (correctly pointed at .exe by 0002-non-unix-configure-pyvenv.patch).
  CreateProcess doesn't understand #! shebangs, so an earlier shebang-script attempt
  at that path failed with CreateProcess: %1 is not a valid Win32 application. Worse,
  the regeneration isn't one-time: the real ninja -j... pass triggers it again,
  silently re-clobbering the earlier sed-based build.ninja fix
  (patch_windows_build_ninja) before the real build reaches that target.

  Since CreateProcess only cares about PE content, not the filename extension, the fix
  copies conda's real meson.exe launcher to **both** pyvenv/Scripts/meson.exe and
  the bare pyvenv/Scripts/meson. Whichever spelling ninja invokes, across any number
  of implicit regens, CreateProcess succeeds. This is a workaround, not a fix: "make
  sure the right name gets written" loses a timing race against a regen the recipe
  doesn't control, and shebang scripts are a non-starter - there is no shell in the
  loop for this custom_target.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/qemu-system/recipe.yaml) and found it was in an excellent condition.