feat(toolchain, pip.parse): introduce a new '_host' toolchain repo

[aignas]

This is for passing it in repository_rules and relies on the canonical
label representation introduced in bazel 6.0 and symlink support (needs
to be present on Windows) to work.

This allows the users to not need to load the interpreter label from
a .bzl file but instead specify the label in the form of
@<mytoolchainrepo>_host//:python.

In order to make it work robustly on Windows, we do
repository_ctx.path(python_interpreter_label).realpath to get the actual
path of the Python interpreter on both, bzlmod and non-bzlmod setups on
Windows within the whl_library repository rule.

Work towards #1643.

[rickeylev]

Oh this is gonna be tough to remember. @chrislovecnm do you remember what the issue was with windows and trying to symlink to the python interpreter from another repo?

[rickeylev]

Ah, this might be it: #1265

Something about: the symlink can't be executed directly / powershell issue / dll's can't be found from the symlink's location ?

[aignas]

I am wondering then why the CI is still passing. Maybe the
repository_ctx usage is good enough with symlinks, because
the symlink gets always resolve the real path before executing?

Just to be explicit, I am not using the symlink in toolchain
resolution. For that we already have the alias repos and this
is only for the repository_ctx usecase and the Windows CI seems
to be still happy. Do we need to make this host_python repo
internal to rules_python in some way?

[aignas]

Yeah, the previous path.realpath usage was only on Windows bzlmod, when I enabled it for everything, it started working again (the multi-python-version tests on non-bzlmod started failing because the path.realpath workaround was missing there.