Force loading Python rules from rules_python repo

[brandjon]

Similar to #8741 and #7643, force users to load bazelbuild/rules_python in order to access the built-in Python rules. This allows us to migrate these rules from native to Starlark without necessarily forcing users to migrate every step of the way. The incompatible change flag will be --incompatible_load_python_rules_from_bzl.

Checklist:

• Re-export or copy bundled symbols to bazelbuild/rules_python
• Fix rules_python's workflows for precompiled binaries and documentation generation
• Rename its canonical workspace to @rules_python
• Give the Bazel source tree an internal-only mechanism for replicating rules_python's behavior without loading it
• Update all uses of Python in the Bazel source tree (possibly excluding tests and examples) to use the internal mechanism, including the third_party/ tree
• Update help and error strings in Bazel to reference @rules_python instead of @bazel_tools
• Add the incompatible change flag
• Add automated buildifier fixes
• Migrate bazelbuild/rules_python and google/subpar for flag flip
• Update Bazel tests for flag flip
• Flip default at head

[brandjon]

The Python rules API consists of the following symbols:

• Native rules: py_library, py_binary, py_test, py_runtime
• Native providers: PyInfo, PyRuntimeInfo
• Starlark-defined rules and aspects: py_runtime_pair, find_requirements
• Targets related to selecting on the version: :python_version, :PY2, :PY3
• Targets related to defining a toolchain: :toolchain_type, :py2_interpreter_path, py3_interpreter_path
• Predefined toolchains: :autodetecting_toolchain, autodetecting_toolchain_nonstrict

The two main goals are to

1. make these things accessible through rules_python, either by re-exporting them or by copying their definitions; and
2. make these things inaccessible when rules_python is not used.

In the case of 2, the main priority right now is to prohibit access to the native rules, but not necessarily the other symbols right now, since that would in general require implementing new mechanisms for whitelisting.

[brandjon]

Update: We will be deferring this until Bazel 2.0. In the meantime, projects can and should continue to migrate to using rules_python and not rely directly on bundled Python rules APIs. Note that currently migration is automated with buildifier except for adding the entry to the WORKSPACE file.

[abergmeier]

Soo we are at Bazel 3.0 by now. Any update on when this could happen?

[fmeum]

@lberki The Python runfiles libraries are in a weird state: Their usage instructions recommend to load them from @rules_python, but that repo isn't defined in a default WORKSPACE. If the current issue isn't expected to be resolved soon, e4ccba4 should probably be reverted.

The actual rules_python repo has its own version of the runfiles libraries forked at a time where it still referred to @bazel_tools: https://github.com/bazelbuild/rules_python/blob/a2b7f4288fc7ad4ed387aa20cb2d09bf497a1b10/python/runfiles/runfiles.py. We should clarify what the source of truth is.