Create a pipeline for microsoft/go releases

[dagood]

The basic requirements to do a release are:

• Make a signed tag and push it to the repository.
• Download the source archives from a target build to attach to the GitHub release.
• Create a GitHub release on the signed tag.

There's more to do on the Docker side--sticking to microsoft/go here.

We can use add some basic validation:

• Make sure the commit the release is based on is actually the upstream tag, and that it's the correct tag. (Don't release the wrong build, or release a build that is based on an upstream commit before or after the release tag, or a build of the wrong branch entirely.)
• Make sure the tag doesn't overlap an existing tag.
• Multi-person signoff.
• Make sure the source archive's format matches what we expect. E.g. root go folder, no files outside that folder, certain directories exist inside the folder, the archive filename matches expectations, checksum and signature are accurate, ...
• Run additional test jobs on the source. (Rolling build.) This could increase coverage if our rolling build schedule just happened to miss the real release commit.

---

• Update boring branch VERSION file automatically #470
• Sync-from-upstream infra should attempt to fix up patches with 3-way am if patches don't apply cleanly #542
• Update MICROSOFT_REVISION file automatically during release process #575
• Release automation should maintain a concise list of all release-related builds #605

[dagood]

This would be really nice to have:

• Poll https://github.com/golang/go/blob/dev.boringcrypto/misc/boring/RELEASES for changes. Automatically create boring branch update PR when the target version number is detected in that file.

When someone kicks off the pipeline (due to a Go announcement), at that time the release branch commits are done, and we know what the new Go version is, but boring branches are (probably) not updated yet. Automating the polling process removes a human delay from the critical path.