Conflict with multiple Python versions

We have a monorepo with multiple Python projects on different Python versions. The problem is that with bzlmod, `rules_python` namespaces requirements such that they only work on the specific version of Python it was installed for. So even if we configure two mypy aspects, one for project A on 3.10 and one for project B on 3.11, when mypy_aspect_A is applied to project B, it'll try to load A's deps in 3.11 and fail with
```
The current build configuration's Python version doesn't match any of the Python
wheels available for this distribution.
```

Workarounds:
* Install A's deps and B's deps for both 3.10 and 3.11
* Don't automatically apply the aspects in `.bazelrc`, manually specify it when building the relevant project

Related: https://github.com/bazel-contrib/rules_python/issues/2530

---

The problem arises because the mypy aspect takes in the type_mapping as Targets, which is needed in order to get information about `types-foo`. Because `type_mapping` is passed as Targets via `label_list()`, applying the aspect will resolve the label into a Target.

Say we have a workspace with project A on 3.10 with mypy enabled, and some unrelated project B on 3.11. The mypy aspect will be configured for project A (e.g. `opt_in_tags = ["typecheck_A"]`), with type_mapping containing the equivalent of `requirement_A("foo"): Target(requirement_A("types-foo"))`. When Bazel builds project B, the mypy aspect won't execute anything (since none of B's targets will have the `typecheck_A` tag), but the mypy aspect **will still resolve A's targets**. Since Bazel is building B, it's using Python 3.11 and resolves A's targets against 3.11, and error since A's deps are namespaced to 3.10, not 3.11

This might be solvable with the new experimental `propagation_predicate` field, to filter out `opt_in_tags` before resolving the labels, but that won't exist until Bazel 9: https://github.com/bazelbuild/bazel/commit/c37ab58807105f6af9a78044b572c8852e680b11

Start with the mypy aspect's type_mapping and opt_in_tags configuration, then inspect the .bazelrc usage described in the issue. Reproduce the two-project setup with Python 3.10 and 3.11 and verify whether untagged targets still resolve the other project's labels. Done means the unrelated project's build no longer fails because of the other version's dependencies, or the limitation is clearly documented.

Written by the indexing model from the issue text.