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

[rickeylev]

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

[f0rmiga]

Don't need my review on this?

[rickeylev]

I don't think so? Nothing behavior changing AFAIK. If you see an issue, though, feel free to point it out.