Add bzl_library support for @bazel_tools

[brandjon]

(Maybe this belongs in Bazel's component.)

It was mentioned on the Slack that you can't define a bzl_library for your own .bzl files if they load files in @bazel_tools. At the same time, we can't just naively add bzl_library targets for each .bzl in @bazel_tools because it would make Bazel depend on skylib. The user also can't define their own bzl_library targets for the files in @bazel_tools due to visibility / exports_files issues.

As a somewhat clunky workaround, I suggest that we export all .bzl files underneath @bazel_tools with visibility granted to a specific subpackage, e.g. @bazel_tools//bzl_exports. That subpackage would load bzl_library from skylib and re-export these as bzl_library targets. This way, users who have skylib can depend on this subpackage, and users who don't have skylib will have no need to import it.

[aiuto]

How about we invert this to be: Add bzl_library support to @bazel_tools.
The situation we have today is that every rule set that wants to generate docs has to have a WORKSPACE dependency on bazel-skylib.

For long migration, we can still keep the declaration here, but just re-export the @bazel_tools version.

Pros:

• small rules that want to use it for structuring don't have to add a transitive dep on skylib
• If someone needs to pin to a specific version of skylib and rename it, the StarlarkLibraryInfo provider will, still refer to the one in bazel_tools, so their bzl_library rules will still interop with ones from dependent libraries.

[brandjon]

Update: We still need to come up with a coherent best practice for accessing @bazel_tools .bzl files as bzl_library targets. On reread, I'm not particularly fond of the clunky workaround I suggested above.