import rules_python doesn't work under bzlmod

# 🐞 bug report

This is the rules_python issue for https://github.com/bazelbuild/bazel/issues/18128

### Affected Rule

Import the runfiles library via the `@rules_python//python/runfiles` depending as `import rules_python.python.runfiles`

### Is this a regression?

Effectively, yes. The established name for the libraries rules_python provides are under the "rules_python" namespace.

### Description

In bzlmod, `import rules_python.python.runfiles` doesn't work. It works for workspace builds.

This is because, in bzlmod, the directory names of repos in runfiles changes from "foo" to "foo~version" (where version is the module version plus some other parts). Such a name isn't importable because it can't be known in advance, and isn't a valid python package a name.

## 🔬 Minimal Reproduction

* Create a py_binary
* Depend on `@rules_python//python/runfiles`
* Do `import rules_python`

An import error will occur.

### Analysis

Fixing this is _sort of_ straightforward -- we need to get a directory onto sys.path that has a rules_python sub-directory.

Some complicating factors are:
1. We need `import python.runfiles` to continue working. This is the name we told people to use in the meantime, so we'll need to stick with that.
2. We want to avoid double imports, e.g. the same file being compiled twice; this is what happens if you do "import rules_python.python.runfiles.runfiles" and "import python.runfiles.runfiles" in a workspace build today (Python keys things by the _module name_, not the underlying file name)
3. Repo roots are still on sys.path and explicit init generation is still enabled by default. This means, wherever we create a sub directory, its top-most directory is going to end up on sys.path. This means a standard src-based layout might be prone to breaking things, as dependents might be relying on `import src.bla.bla` themselves. This came up via slack, where I've seen people recommend using a repo-relative import name like `import src.bla`.
4. Pip-based dependencies use `import runfiles`, so we have to be not interfere with that
5. The runfiles code uses its own path to help location the runfiles root, so make sure to update that; this is an internal detail; just noting it for myself
6. Personally, I worry that _something_ is relying on the `$repoRoot/python/runfiles/runfiles.py` file existing. So I'm hesitant to move that file. I don't know what or why that would be the case though, so perhaps I'm being

Start with the minimal reproduction: create a py_binary, depend on @rules_python//python/runfiles, and test imports under bzlmod and workspace builds. Read the runfiles library entry point and compare the generated runfiles paths and sys.path behavior. Done means import rules_python.python.runfiles and import python.runfiles both work without duplicate imports, while pip-based import runfiles remains unaffected.

Vom Indexierungsmodell aus dem Issue-Text verfasst.