feat: Derive c_stdlib build variants from system requirements

[hunger]

Derive c_stdlib build variants from system requirements

Problem

When pixi-build builds a compiled (non-noarch) package, the C stdlib target is
selected through conda-forge's c_stdlib / c_stdlib_version build variants
(consumed by the stdlib('c') recipe function). Today users have to spell those
out by hand in [workspace.build-variants], even though pixi already knows the
target from the workspace's platforms.

Changes

Derive the variant pair from system requirements (pixi_core)

Workspace::variants now derives c_stdlib / c_stdlib_version from the
platform's declared virtual packages and fills them in only where the user
hasn't set them explicitly (an explicit [workspace.build-variants] entry
always wins):

subdir	virtual package	c_stdlib	c_stdlib_version
osx-*	__osx	macosx_deployment_target	the __osx version
linux-*	__glibc	sysroot	the __glibc version

Windows is skipped (no meaningful stdlib version), and a platform with no
matching virtual package derives nothing rather than inventing a value. The
logic lives in the new crates/pixi_core/src/workspace/stdlib_variants.rs.

__musl and __cuda are noted as follow-ups (TODO(#6175)). They are not fully described
in any CEP, so whatever we do there is goiung to be incomplete.

Set MACOSX_DEPLOYMENT_TARGET on macOS (pixi_build_python)

For compiled macOS builds where the c_stdlib_version variant is present, the
python backend injects MACOSX_DEPLOYMENT_TARGET=${{ c_stdlib_version }} into
the build-script env (rendered lazily by rattler-build). It's skipped for noarch
builds, off macOS, and when the variant is absent. An explicit
MACOSX_DEPLOYMENT_TARGET in the backend config is left untouched — the derived
value only fills the gap.

Tests

• Unit tests for derive_stdlib_variants (osx, linux, windows-skipped,
  glibc-absent, and bare-subdir defaults).
• Unit test that an explicit build-variant overrides the derived value while an
  unset key is still filled in.
• Unit tests for macos_deployment_target_env and two end-to-end
  generate_recipe tests (derived value wired in; user config respected).
• New integration test test_macos_deployment_target_from_system_requirements
  plus fixture tests/data/pixi-build/system-requirements-osx-python pinning
  macos = "12.0" (deliberately different from the 13.0 osx-subdir default).
  It asserts a single compiled artifact is produced on every platform, and on
  macOS that the build script env carries MACOSX_DEPLOYMENT_TARGET=12.0.

Fixes #6175.

AI Disclosure

• This PR contains AI-generated content.
  • I have tested any AI-generated content in my PR.
  • I take responsibility for any AI-generated content in my PR.

Tools: Claude

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added sufficient tests to cover my changes.
• I have verified that changes that would impact the JSON schema have been made in schema/model.py.

[baszalmstra]

I think (not entirely sure) that conda-forge adds MACOSX_DEPLOYMENT_TARGET as a variant too.

Nope thats wrong. Its handled by the macosx_deployment_target package.

[hunger]

This should mostly work, but it has severe trouble in the presence of "old" lockfiles. That needs looking into still.

[hunger]

We report better build variants to the build backend, which filters them and hands them back to us, so we can store them in the lock file. So this PR does invalidate lock files. I think that is what we need to do in this case and users will benefit from better builds.

I have no Mac to test this on, but the linux side works reliably, and the mac shows up with the expected variants in the lock file, so I am positive this works as expected.

Windows is unchanged, nothing to test there.

The examples/pixi-build/cpp-sdl is a small example to test this with, but all the pixi-build examples should work just as well.

[wolfv]

I am going to ping @h-vetinari as he might have some opinions here and I would love his input.