Branch name consolidation and release flow

[jonasbardino]

With the edge branch practically in production on our own core long-running production sites and the on-going migration to experimental everywhere with python3 as default we should really get rid of those outdated and misleading branch names.

We have discussed renaming experimental to next and edge to the github default main plus make the latter the default branch in clones. We need to preserve backwards compatibility in relation to the branch names in docker-migrid envs etc. so the renames either means clone and alias them to the old names or preserve those old branches and sync back changes there for a while. That sync should be possible to do automatically with a github action.
That will additionally allow us to merge next into main at some point when we decide to completely switch to python3. If needed we can make a legacy branch copy at that time and keep it around for extended support.

While at it we should also adjust releases and tags here to specifically point at one of those branches rather than master. Otherwise it's not obvious for admins of partner sites not using the master branch how to obtain and use a matching git revision for a given release / tag.
A proposed solution would be to use Main-YYYYMMDD / v2.x and Next-YYYYMMDD / v3.x respectively for new such releases / tags pointing to those branches specifically in line with the Stable-YYYYMMDD / v1.x we have used so far pointing to master.

[jonasbardino]

docker-migrid switched to next and main as defaults now and the coming migrid Main and Next releases will start using those branches as their source, while preserving sync with the old experimental and edge branches for backwards compatibility.