doc, ci: Improve release process

[langston-barrett]

The CI setup builds and uploads artifacts to Github releases when I push a new tag (i.e., version). Sometimes, something has changed about the way the project is built, and building the release artifacts fails. This is unfortunate - the CI has failed on a tag that has already been pushed to the remote, and I can't make a release because it won't have the right artifacts. It seems I have a few options, with different trade-offs:

1. Delete the tag (locally and on the remote), make a new commit (or revise the previous commit), push it and the tag back to the remote. This seems bad in all the ways git push --force main is bad.
2. Make pre-releases, e.g. v0.1.0-rc.1 to test the CI build for releases. This seems good, but what if it takes me a few steps to fix it? Then I might end up with a dozen release candidates, cluttering up my git tags.
3. Build release artifacts on every CI build, or at least builds on the main branch. The problem with this is that it takes a long time - in particular, it's important to compile the project with high optimization for releases, but the project contains a huge generated C++ file that takes forever to compile with such optimizations.
4. Build release artifacts manually, on my machine. This is sub-optimal because I might mess it up - perhaps by having a dirty work tree.
5. Set up a manually-triggered workflow to build the release artifacts, make sure it passes before tagging a release.
6. Create a release branch, have CI build (but not upload) artifacts on every push to that branch. Start pushing main to that branch whenever preparing for a release, cut a release only when everything works.

(6) seems best to me at the moment. Need to implement and document it.