Automatically create crypto backends release branch and tags

[qmuntal]

The first time a crypto backend needs to get a fix backported into a Go minor release someone has to go to the backend repo and create a release branch from the commit that was used the create that release. This process is manual and error prone, and using the wrong commit is really disruptive.

I propose that the release process automatically creates a new release branch on every crypto backend at the correct commit, taken from the src/go.mod, the first time a minor release is created (that is, go1.x.0). While here, it could also push a tag in the form of go1.x, being x the Go toolchain minor release. That would not follow semantic version, but that's fine, our main use case is the Go toolchain, not external uses. Having the tag would make it easier to manually, or automatically, compare what changes in between two Go minor versions.

[dagood]

A few implementation-ish details discussed in sync that mean this is actually doable without getting the release pipelines into better shape overall:

I propose that the release process automatically creates a new release branch on every crypto backend at the correct commit, taken from the src/go.mod, the first time a minor release is created (that is, go1.x.0).

We don't currently have any "new major"-specific automation in place (#267), which initially seems like it would make this harder. But actually, this is easy to do without the release pipeline knowing whether the release is a new major: simply create the branch only if it doesn't already exist in the backend repo. (Semi-idempotent.)

While here, it could also push a tag in the form of go1.x, being x the Go toolchain minor release.

Just to point out: it's not possible to use this tag (or any version tag created at this point in the release process) in the microsoft/go go.mod, because it's too late. But that's not the point--the easy browsing while in the backend repo is the point, and sufficient to make this worthwhile.

We all agree we don't see a convincing reason to go out of our way to use tags in the go.mod to refer to the backend repo. We expect that nobody uses it as a "normal" Go module that could benefit from the backend having nice semver-style tags, and it wouldn't be trivial to maintain those tags.