fix: fixes to prepare for making bootstrap=script the default for Linux (#2760)

Various cleanup and prep work to switch bootstrap=script to be the
default.

* Change `bootstrap_impl` to always be disabled for windows. This allows
setting it to
true in a bazelrc without worrying about the target platform. This is
done by using
FeatureFlagInfo to force the value to disabled for windows. This allows
any downstream
usages of the flag to Just Work and not have to add selects() for
windows themselves.
* Switch pip_repository_annotations test to `import python.runfiles`.
The script bootstrap
doesn't add the runfiles root to sys.path, so `import rules_python`
stops working.

* Switch gazelle workspace to using the runtime-env toolchain. It was
previously
implicitly using the deprecated one built into bazel, which doesn't
provide various
  necessary provider fields.
* Make the local toolchain use `sys._base_executable` instead of
`sys.executable`
when finding the interpreter. Otherwise, it might find a venv
interpreter or not
  properly handle wrapper scripts like pyenv.
* Adds a toolchain attribute/field to indicate if the toolchain supports
a build-time
created venv. This is due to the runtime_env toolchain. See PR comments
for details,
but in short: if we don't know the python interpreter path and version
at
  build time, the venv may not properly activate or find site-packages.

If it isn't supported, then the stage1 bootstrap creates a temporary
venv, similar
to how the zip case is handled. Unfortunately, this requires invoking
Python itself
as part of program startup, but I don't see a way around that -- note
this is
  only triggered by the runtime-env toolchain.

* Make the runtime-env toolchain better support virtualenvs. Because
it's a wrapper
that re-invokes Python, Python can't automatically detect its in a venv.
Two
tricks are used (`exec -a` and PYTHONEXECUTABLE) to help address this
(but they
  aren't guaranteed to work, hence the "recreate at runtime" logic).
* Fix a subtle issue where `sys._base_executable` isn't set correctly
due to `home`
missing in the pyvenv.cfg file. This mostly only affected the creation
of venvs
  from within the bazel-created venv.
* Change the bazel site init to always add the build-time created
site-packages
(if it exists) as a site directory. This matches the system_python
bootstrap
behavior a bit better, which just shoved everything onto sys.path using
  PYTHONPATH.
* Skip running runtime_env_toolchains tests on RBE. RBE's system python
is 3.6,
but the script bootstrap uses 3.9 features. (Running it on RBE is
questionable
  anyways).

Along the way...

* Ignore gazelle convenience symlinks
* Switch pip_repository_annotations test to use
non-legacy_external_runfiles based
  paths. The legacy behavior is disabled in Bazel 8+ by default.
* Also document why the script bootstrap doesn't add the runfiles root
to sys.path.

Work towards https://github.com/bazel-contrib/rules_python/issues/2521

---------

Co-authored-by: Ignas Anikevicius <240938+aignas@users.noreply.github.com>