Provide a macro to register multiple go toolchains

[sluongng]

Today, we are registering go toolchain using go_register_toolchains() which will automatically detect existing go_download_sdk_rule() and the like.

If there is no existing rule, go_register_toolchains will invoke a default go_download_sdk_rule to register 1 Go SDK using current host platform.

This is a problem, however, for setup which want to do cross-compilation using Remote Build Execution.
For example, invoking an RBE build from a MacOS Arm64 platform like this

bazel build //:target --cpu=k8 --host_cpu=k8 ... --remote_executor=grpcs://my-executor.com/

Would require a Go toolchain that's compatible to the platform specified on the build flags, not current-host-compatible registered SDK.

A workaround for this is to manually define multiple go_download_sdk() in WORKSPACE like this https://github.com/buildbuddy-io/buildbuddy/blob/73ec4544d3bf813141314970275d4c2eaa5091a8/WORKSPACE#L57-L83

---

It would be better / more ergonomic if we could use go_register_toolchains() to register multiple toolchains based on the result from a combination of:

• https://go.dev/dl/?mode=json&include=all result
• a version attribute
• a selected list of platforms, similar to sdks attribute in go_download_sdk

The desirable outcome should be something like this:

go_register_toolchains(
  version = "1.20.3",
  platforms = [
    "linux_amd64",
    "linux_arm64",
    "darwin_amd64",
    "darwin_arm64",
  ]
)

[sluongng]

For endgame, we probably want something like cc_toolchain_suite. But that's implemented in Java and for cc rules only.

[fmeum]

I would go further: With no platforms specified, why not register toolchains for all reasonably common OS/arch combinations? Now that Go SDKs aren't fetched eagerly anymore, registering toolchains is cheap.

As far as I know cc_toolchain_suite predates toolchain resolution. Registering multiple toolchains and relying on resolution should replace its use cases pretty well.