[Policy] Branch Naming: Convert from version-specific to 'main' dev branch

Problem/Motivation

Background: We currently do most of our development against the "Most recently opened Development Branch", and when the first alpha of that minor is released, we open a new branch, which then logically changes what the "Most recently opened Development branch". Anything that's eligible to apply to either the currently supported minor or previous minor (security patches) is then cherry picked to those lower branches.

Problem: This means that our "logical HEAD" of core is a moving target that changes every six months, and perhaps more frequently when we add in Major version branch openings as well.

This causes a couple of problems:

1. Issues are assigned to a specific branch, like "9.3.x" that then have to be re-assigned to the new logical HEAD. In the vast majority of cases these issues aren't actually targeting the specific branch, they are trying to chase the logical HEAD, and when that HEAD changes labels (i.e. from 9.3.x->9.4.x) we have to go through a process to manipulate all of the issue metadata to move them.
2. Now that we have merge requests, those MRs also need to be migrated to be filed against the latest logical HEAD. We currently do not have a programmatic way to accomplish this, and the permissions on gitlab only allow the opener of the MR to do it, so even manual community issue grooming is onerous, and sometimes demands a new MR be opened to move branches.
3. A new user to the project doesn't have an obvious signpost where development happens. They have to look at all the open branches, and deduce that the highest numbered one is where all the momentum is happening. -> it is more common in projects for main is the place where work happens.

Proposed resolution

Proposal: Change our logical HEAD to main. All of our current existing policies would still apply, with one exception: instead of opening "the next branch for development" when we release an alpha, we instead open the release branch for that release at the time the alpha is released. (Do nothing with d7 and leave it as it is)

Example

(Now out of date in terms of current version, but still conveys the idea)

The current regime:
All of our commits happen to 9.3.x and:

The proposed strategy:
(rename current 9.3.x to main)
All of our commits happen against the main branch

So essentially: we develop in main untilwe open a release branch, at the same time that we make that branch's first release.

Question: The one part of this change that I'm unfamiliar with is what we do around major version branch releases:

If we are opening 9.4.x and 10.0.x at different times, then with this change in place we would open the 9.4.x branch when we are ready to start committing '10.0.x only' changes to main

Implementation considerations:

• Add main as a 'dev' release?
• Do we need both a 'main' and a 'next'?
• Allow main to exist in the version selector for issues
• Look at places where 'branch' might be standing in for a version.
• disable force pushes to main - at least for core.

Remaining tasks

• Finalize decision
• Identify all places where there are hard coded assumptions about 'branch' and 'version'
• Choose an appropriate transition window in an upcoming version cycle

User interface changes

Release notes snippet