@bazel_tools//src/main/protobuf reference missing runtime

### Description of the problem:

Bazel commands like aquery output protobufs in formats described in `@bazel_tools//src/main/protobuf`. This would make building tooling on top of them amazingly easy...except that the py_proto_libraries specify runtimes and protoc's from `//third_party/protobuf`, which doesn't seem to be included in @bazel_tools. No fun! So then you can't use the bundled definitions, and end up copy pasting code, or parsing JSON, rather than taking the happy path Bazel (almost) built.

Either using normal protoc and runtime or bundling the runtime and protoc required by the tooling exposed would fix this issue.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Try referencing `@bazel_tools//src/main/protobuf:analysis_v2_py_proto` in a Bazel rule. It'll error out, complaining that the `@bazel_tools//third_party/protobuf` doesn't exist. Which, checking the filesystem, indeed does not.

#### Platform details
macOS 11, Bazel 4.0.0 -- the latest at the time of writing.

#### Related

#8738 discusses problems with the java versions of these rules--the only other way in though @bazel_tools. You used to be able to hack your way around this by having the grpc proto rules reference the raw proto_libraries, but the python protobuf runtime tightened up its checks enough to block the import-path hackery needed to make this work.

Reproduce the failure by referencing @bazel_tools//src/main/protobuf:analysis_v2_py_proto and inspect its dependency on @bazel_tools//third_party/protobuf. Trace the py_proto_libraries and the referenced protoc/runtime paths described in the issue. Done means the bundled analysis protobuf target can be consumed by a Bazel rule without a missing runtime or protoc dependency.

Written by the indexing model from the issue text.