Support python_version on modules_mapping and/or gazelle_manifest rule

# 🚀 feature request

### Relevant Rules

* [gazelle_python_manifest](https://github.com/bazel-contrib/rules_python/blob/main/gazelle/manifest/defs.bzl)
* [modules_mapping](https://github.com/bazel-contrib/rules_python/blob/main/gazelle/modules_mapping/def.bzl)

### Description

When in the middle of working on a Python version upgrade, it's valuable to generate gazelle manifests with different module maps because you the requirements.in may include additional requirements for the new python version:

```
gradio; python_version >= "3.11"
```

When running the manifest rule with all_whl_requirements, it'll fail with something like:
> No matching wheel for current configuration's Python version.

In order to get the desired behavior, we need to run the gazelle manifest update by specifying a different python version via command line `--@rules_python//python/config_settings:python_version=3.11`.

### Describe the solution you'd like

Adding a `python_version attribute to the manifest or modules_mapping rule, so that we can run it with the expected python_version as needed without a command-line flag.

### Describe alternatives you've considered

We currently customize our scripts so that we add the command line flag, but I don't think this is feasible.

Other alternatives:
* Generate a modules mapping per different environment tag satisfied in the requirements.in . This might be heavy-handed, but could work for all other environment markers beyond python_version . And there's no need to maintain multiple manifest files.

Start with gazelle/manifest/defs.bzl and gazelle/modules_mapping/def.bzl, then review how the manifest rule uses all_whl_requirements and the command-line python_version setting. Done means either rule accepts the requested Python version and generates the matching manifest or module map without the command-line flag, with behavior covering version-conditioned requirements.

Written by the indexing model from the issue text.