Mark bzl_library as providing StarlarkLibraryInfo

[fmeum]

Work towards bazelbuild/bazel#18599, but useful even without it as it allows custom aspects to collect bzl files to generate docs for.

[fmeum]

@tetromino I have a prototype of the validation aspect for bzl_library ready. My plan is to keep the definition of StarlarkLibraryInfo in Starlark (possible thanks to StarlarkProviderWrapper in Bazel) and even in bazel_skylib (I think that we can retrieve the canonical repo name of Skylib from bazel_tools' repo mapping). In any case, this change will be needed to make that aspect work.

[tetromino]

My plan is to keep the definition of StarlarkLibraryInfo in Starlark (possible thanks to StarlarkProviderWrapper in Bazel) and even in bazel_skylib (I think that we can retrieve the canonical repo name of Skylib from bazel_tools' repo mapping)

@fmeum, if the provider symbol is defined in skylib, this means @bazel_tools cannot use it for its own equivalent of bzl_library (since bazel_tools cannot depend on skylib).

Wouldn't that mean that we risk a repeat of bazel-contrib/rules_go#4394?

[fmeum]

If we want to get to the point where bazel_tools has no deps whatsoever then we should not put the provider into bazel_skylib, that's true. For now bazel_tools has many more steps than zhat. We could eventually move the provider into bazel_tools and have bazel_skylib redirect to it depending on the Bazel version.