Change CI release logic

[jgiannuzzi]

This PR changes the CI release logic in the following way:

• add a workflow create.yml to create release branches and tags in a controlled manner, using a GitHub app that will have exceptions in the rulesets
• change the release.yml workflow to be directly called by the main CI workflow
• change release.yml to not validate the ref anymore, but instead rely on rulesets and environments
• add support for prereleases
• document workflow in docs/maintainer.md

---

The following tasks need to be completed before merging this PR (more information can be found in the documentation):

• create and install a new GitHub app
• add its credentials to a new create-release environment that can only be accessed by the main branch
• add the required rulesets — this has to be done before the next step!
• change the release environment to also allow v* tag patterns (and keep the existing main branch)

---

Examples on a repo that has been setup as described and as "upstream" (so not a fork, but in this case a copy):

Note

Many of these links may require to be reloaded before they display the actual log line I want to show — this seems to be a GitHub bug at the time of writing

• Run on main: notice in particular that the main and edge tags are published on Docker Hub
• Run to create a 0.3 release branch: notice in particular that the app/bot is able to bypass the branch creation rule to create the branch
  
• Run on the 0.3 release branch: notice that the release workflow is skipped
• Run to create a 0.3.5-beta.1 tag: the app/bot can bypass the tag creation rule
  
• Run on the 0.3.5-beta.1 tag: notice that the latest tag does not get published on Docker Hub, that the GitHub release is created as a prerelease, and that the website does not get updated for the announcement — PyPI publishing does not work intentionally because it would have required changing the package name
• Run to create a 0.3.5 tag: the app/bot can bypass the tag creation rule
• Run on the 0.3.5 tag: notice that the latest tag is published on Docker Hub, that the GitHub release is created as a normal release, and that the website gets updated for the announcement — PyPI publishing does not work intentionally because it would have required changing the package name
• Run to create a wrong 0.04 release branch: notice the error message
• Run to create a wrong 0.3.5beta.1 tag: notice the error message
• Run to create a 0.4.5 tag when the 0.4 branch does not exist: notice the error message

[suprjinx]

LGTM

[dave-gantenbein]

I hardly feel qualified with this level of github-fu, lets push it and see if it breaks, with rollback being easy enough.