Introduce release workflow

Since I'm more an engineer and less a developer, I want to put ideas up for discussion. How about the following:

• As soon as we tag 1.0.0 we introduce a support/1.x.y branch. Whenever we add non breaking changes to the repository, we merge into that instead of main. If the merge succeeds, we merge this support branch into main
• When we introduce breaking changes, we merge directly to main
• When we see the time coming for a new major release, we start a rc/2.x.y branch. Non breaking changes from support will also be merged into this branch
• When all issues targeting the new release are closed, we tag rc1 from the rc branch. We'll ask users to test this rc and report issues. When all these issues are fixed, we'll tag rc2and so forth. Only when there are no changes besides docs and comments, the last RC will be tagged as the new release
• We aim on supporting the current major release and the last major release
• The rest is documented as "semantic versioning"

Start with the proposed support/1.x.y and rc/2.x.y branch flow, then compare it with the repository's current release process. Review how tags, release candidates, and semantic-versioning guidance are currently handled; done would require an agreed workflow and documented implementation.