Upload binary builds to microsoft/go releases to avoid sync issues

A backlink from this issue alerted me to a scenario that we can improve:

• https://github.com/elastic/golang-crossbuild/pull/596

Currently our GitHub Release entries only include a source tarball (and its checksum/sig).

The issue is that when we publish a GitHub Release, that notifies people (and their tooling, etc.). There isn't currently a way to reliably get from the GitHub Release to our prebuilt binaries. In https://github.com/elastic/golang-crossbuild/pull/596, they assemble an aka.ms URL, but due to a release interruption, it wasn't available yet. And even if there weren't a release interruption, there's a race between updating the aka.ms links, publishing the GitHub release, and consuming the download.

A few ways to resolve this scenario:

• Publish aka.ms URLs strictly before the GitHub Release.
  • But will the inverse scenario show up? (Someone infers from our aka.ms links changing that a GitHub Release will be available?)
• Also put our binaries in the GitHub Release.
  • Then nobody has to infer that certain aka.ms URLs will exist due to the Release existing.
  • I'm not aware of a significant reason not to do this. At the time, we didn't simply because it takes longer to get the upload done and uses up space, and all Azure Linux required is that we include the patched source code.
  • Simply a nice thing to do to make it easier to use our builds.

There may have been a concern at the time about accessing our builds through an approved channel (download center) vs. unapproved, but this is the choice of the team using our binaries and choosing which endpoints to depend on. Our existing channels will still exist.

Start by reviewing how microsoft/go GitHub Releases and the existing aka.ms binary URLs are published, including the timing between those steps. Done means the prebuilt binaries are attached to each GitHub Release so consumers can retrieve them reliably without depending on a release-time URL race.