Context: bazelbuild/bazel-central-registry#28

RELNOTES: None
PiperOrigin-RevId: 406334617

Modules can specify the workspace_name attribute to allow accessing its
own targets under the repo name.

This helps make migration easier when the preferred workspace name is
different from the module name of the project.

Context: bazelbuild/bazel-central-registry#28 (comment)

The label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf").

Note that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it's necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives.

See bazelbuild/bazel-central-registry#28 (comment) for a bit more context.

* Use repo-relative labels wherever possible

The label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf").

Note that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it's necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives.

See bazelbuild/bazel-central-registry#28 (comment) for a bit more context.

* fix protobuf_deps.bzl