Make release workflow compatible with immutable releases

[aarongable]

Separate the release workflow into three sequential jobs. The first simply creates a draft release, the second (which can be multiple parallel jobs, if there's a matrix of go versions) builds all the relevant release artifacts and uploads them to container registries and to the release itself, and the third takes the release out of draft mode if and only if the previous jobs succeeded.

This separation allows us to adopt Immutable Releases, which can provide attestations that release artifacts are not modified after they're created. This is because the release only becomes immutable once it is taken out of draft mode, so as long as it's just a draft, multiple different jobs can upload artifacts to it.

Along the way, make a few other small improvements to the release workflow, such as avoiding directly interpolating ${{ github.ref_name }} and using a pinned version of the docker/login-action to authenticate to ghcr.

Fixes #8380

[aarongable]

Demonstration of this working can be seen on my personal fork of boulder.

First the release is created as a draft:

Then the multi-stage job runs:

And when it's done, the release is successfully populated with artifacts from multiple jobs: