Evaluate release queue concept

"Linearize" multiple parallel conflicting build namespaces for hypothetical release, similar to gitlab's merge trains.

The release queue is not exactly the same as gitlab’s merge train. In a merge train, multiple commits are built in parallel. We need artifacts of previous releases as inputs to the next build, so the release queue is more like a normal queue. The similarity to a merge train comes from the fact that we need to rebase build inputs on the latest main before building and merging branches. This is triggered when a build namespace succeeds and is promoted for release.

In general, our strategy is to build every transitive dependent for any package change, to check that everything still works. After that build succeeds, we want to evaluate strategies to determine what needs to be released.

Once the Release Queue is fully built, we need to take some measurements to avoid inconsistencies during the short window when releasing the queue and merging the branches. To ensure that manual actions by packagers don’t cause conflicts when a large build namespace is released, we want to lock official repositories and package source repositories for a short duration while buildbtw is merging commits and uploading artifacts into repositories.