Support consumer-configured project scoping for python_version #4375

Relevant Rules

@rules_python//python/config_settings:python_version and the root module's Python configuration API.

Description

I build Python extensions for multiple interpreter versions, with large Python-independent Rust/C++ libraries underneath them. The bindings need different Python configurations, but the native libraries should share a configuration when their other inputs are equal.

For example:

Python 3.11 binding -> native core
Python 3.12 binding -> native core

A version transition on a binding also reaches its native dependencies unless that setting is reset. This creates extra configured targets and can change action keys even where the native library does not use Python. Exec-only flag trimming does not address ordinary target-configured libraries.

Bazel's configurability roadmap explicitly describes project-scoped flags as a way to avoid this cache fragmentation; its public example demonstrates the mechanism.

Currently I need a source patch to make the version flag project-scoped and associate it with my project's ownership definition. I would like to configure that through a supported API.

Describe the solution you'd like

An opt-in, root-module-controlled configuration that:

1. Selects project scope for the Python-version flag while preserving the existing default behavior.
2. Associates the flag with a consumer-supplied PROJECT.scl definition, without requiring a patch to the dependency's source tree.

The consumer would own the paths for bindings, intervening aliases, Python headers/runtimes and Python-sensitive build scripts. Python-independent native dependencies would remain outside those paths. The API need not infer that boundary automatically.

Please document the supported Bazel versions and test both target transitions and exec tools. In particular, #4335 deliberately sets universal scope so Bazel 10's precompiler uses the correct interpreter. An opt-in project mode must account for that correctness requirement rather than simply replacing the default.

This request uses Bazel's existing invocation-baseline reset semantics. It does not require the separate declared-default reset proposal in bazelbuild/bazel#32178.

Describe alternatives you've considered

Patching the flag declaration and adding a project-definition alias works as a local workaround, but ties the policy to dependency implementation details. Custom reset transitions require maintaining explicit boundaries and wrappers. A supported project-scoping option would let the ruleset own the integration while the consuming project owns its dependency boundary.