Automate release process

[karfau]

Is your feature request related to a problem? Please describe.
Our security policy states that we are maintaining the last two minor versions.
This is especially relevant for landing breaking changes on the master branch, without doing a release (or just doing a pre-release, for people to be able to try it out), and afterwards being informed about a security issue that has to be addressed.
This is the case while I'm writing it: the latest dist-tag (on npm) is pointing to 0.8.x, the next dist-tag is pointing to 0.9.0-beta.x and we still need to publish fixes to 0.7.x versions, since 0.9.0 has not been released.
Currently we are doing those fixes on branches following the naming convention release-0.7.x and release-0.8.x. But there is no github action workflow configured for those branches, and they are not protected in any way.

Since the current release process involves manual steps, especially for picking the version and updating the changelog, there doesn't seem to be a trivial way to automate the whole process.
We also often merge multiple PRs before we decide to publish a release, to safe time on the release process, but also to group features and fixes into a single release.

Describe the solution you'd like

1. Have fixed branch names for the versions we are supporting/working on, could be something like
   • latest for the currently supported version
   • next for the upcoming version while we are working on it
   • supported for the version that only receives security fixes
2. Automatic pre-releases when pushing to the next and/or the default branch.
   • by limiting it to pre-releases it is not impacting anybody that doesn't want to try the latest stuff
   • we could just use some 0.m.p-YYYYMMDDTHHmm-SHA as the version and not even update the package.json to ignore the whole topic of semantic release, committing back to the repo, etc
3. Add github workflow on latest and supported` branches, to make sure all checks pass.
4. Having this might give us some additional experience to fully automate the release process also for releasing the real version on those branches automatically

Notes:

• I'm not sure to which degree we would still need those release-0.m.x branches, but we could still push to those, and once it's ready trigger a release by pushing that branch to the branches suggested above.
• Would we switch the default branch from latest to next once we land the first breaking changes for the next version?
• THe branch for 0.7.x doesn't even have the changelog and release scripts, so it might make sense to either merge it back in or wait until we no longer need to support it.

Describe alternatives you've considered

• Continue doing all checks by hand

Additional context
Would be happy to learn from projects that have already done something similar. Have not done any research yet, please add information if you have some.

[EricDunaway]

Could publishing to NPM with provenance statements be included with this change?

[karfau]

@EricDunaway that would be ideal, but is not the number one priority.
At least I hope to be able to consider it when selecting the tool for the job.