refactor(pystar): load (but don't use) Starlark implementation. (#1428)

Always loading the code provides several benefits:
  * It's easier to reason about what code paths are taken.
* Iteratively working on them is simply changing an environment variable
instead of editing several files.
  * Ensures the files are loadable on older versions of Bazel.

Usage of the Starlark implemenation is controlled by an environment
variable, `RULES_PYTHON_ENABLE_PYSTAR=1`. An environment variable must
be used because the decision
about which implementation to use must be made before regular build
flags are able to
run (loading phase logic is affected).

The Starlark implementation is almost entirely compatible with pre-Bazel
7, except for the `py_internal` symbol. This symbol is special in a
couple ways:
  * It only exists within the `@rules_python` repo
  * It does not exist prior to Bazel 7.

This requires using a repo rule, `@rules_python_internal`, to do some
feature/version detection to generate a shim bzl file so that the
`py_internal` symbol is always loadable. Regular rules_python code then
loads the shim and can act accordingly.

Also fixes some other loading-time issues (beyond simply py_internal
being None):
* `configuration_field()` args are validated at time of call, so those
must
    be guarded so Bazel 5.4 doesn't fail on them.
* The `init` arg of `provider()` isn't supported under Bazel 5.4; change
them
    to no-op stubs behind a guard.
* The `|` operator for dicts isn't supported under Bazel 5.4; change to
use
    skylib's `dicts.add`


Work towards #1069

WORKSPACE

@@ -34,7 +34,9 @@ local_repository(
     path = "..",
 )
 
-load("@rules_python//python:repositories.bzl", "python_register_toolchains")
+load("@rules_python//python:repositories.bzl", "py_repositories", "python_register_toolchains")
+
+py_repositories()
 
 python_register_toolchains(
     name = "python39",