After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means:
* we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin;
* we need to add proper distribution rules for it;
* we need to update release instructions, since now we will have two distribution tarballs
* Do not register a Go toolchain for ourselves
This module can be used as a transitive dep, and so we want to
avoid forcing users to futz with their SDKs.
* Add a small comment
* Add the gazelle plugin to the distribution
To avoid everyone needing to take a dep on `rules_go`, we
do the following:
1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace`
and call that, and then `bazel_skylib_gazelle_plugin_setup`
2. `bzlmod` users need do nothing, but we now include the
`rules_go` dep in the `MODULE.bazel` shipped in the release.
This is fine, because `bzlmod` will lazily load
dependencies.
* Run buildifier
* Add docstring to `gazelle_setup.bzl`
* Move "internal only" marker
* Make @com_github_bazelbuild_buildtools visible in the deployed module
* Respond to review comments
* Move plugin to a nested workspace
* Run buildifier
* Restore the module declaration from `main`
* Bump versions of rules_go and gazelle used in the top-level module to match the ones in gazelle
* Respond to review comments and add gazelle to ignored directories so //... works as expected
* Add missing descriptor for stardoc
* Move gazelle hints into workspace files
Alexandre Rostovtsev