[Epic] Saner Releases

Goal: Make releases simpler (for the person running them), more transparent (easier to see what is happening), faster (faster), and support how we want to work (monorepos).

The project breaks down into 3 main sections:

1. Because we want our release process to support the monorepo we want to have in the future we need to plan that in first. We already have shared-components monorepo'd with element-web, so by just adding element-desktop back to that mix that should be enough of a foundation to build around.
2. Rework how the release process works. In my opinion a release should almost fully be prepared in a draft along with all relevant artifacts then just hitting publish should publish those artifacts to packages.element.io, dockerhub, etc, etc. This is by far the biggest chunk of work
- [x] Migrate issues from element-desktop -> element-web
- [ ] Analyse and graph the full release process, its dependencies, its artifacts, where they go. Break down the process into stages (draft, rc, release).
- [x] Investigate monorepo tooling for automating a lot of the release process OR Investigate monorepo tooling for helping us resolve the dependency tree to figure out the order we need to release a graph in.
- [ ] Figure out the branch/tag strategy that makes the most sense. Ideally giving us the ability to backport changes to a non-live major version, whilst maintaining tooling akin to backport to aid in hotfixing changes.
- [ ] Changelog management, e.g. towncrier/newsfragments
- [ ] Lots and lots of dry runs in forks
- [x] https://github.com/element-hq/element-web/issues/28146
- [ ] Update CI to be more composable and yarn script driven for common things like linting/tests to automagically pick up new packages
- [ ] Update common tooling e.g. knip with configuration of our monorepo
3. Switch Element Web/Desktop to CalVer as we don't use the semantics of SemVer
4. Switch to immutable releases
5. Figure out a sane way to list non-primary package releases via Github
6. [Stretch] Monorepo everything else, to gain the devx benefit of having a monorepo.
7. [Stretch] Make our releases reproducible

Additional wins from this work: ability to do off-cycle/security or more frequent releases with less time wasted on the release process. Ability for more people to share the release process, current thinking is it might tie in well for the monthly maintainer to own this responsibility.