Simplify handling of PRs by configuring a merge queue

[DiamondJoseph]

As our PRs require that the branch is up to date with the default branch, it can be frustrating to merge multiple dependency updates from renovate: you approve multiple PRs, going to merge the first and the others must merge main into themselves before they can continue.

Configuring a merge queue would allow us to queue up these PRs to sequentially merge one after the other.

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

I believe when we have used this before (was the default behaviour of the repo maybe?) we had not configured the workflow to run on merge_group?

Acceptance Criteria

• PRs don't have to be continually rebased when many are ready at once

[tpoliaw]

I think we should adopt a merge queue for normal, non-renovate PRs as well. It is a pain to have to keep manually rebasing PRs when several are reviewed at the same time.

[abbiemery]

@tpoliaw from reading these, and looking at the branch settings it looks like you either require a merge queue, or you don't use one at all. Do we want to commit to that? (@ZohebShaikh @dan-fernandes )

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue