implement mergify rules for release branches

[geekosaur]

We only handled the case of backports previously, but the current release checklist expects that we can commit PRs to release branches during a release (e.g. changelogs, because we want the list of changelog.d files that are actually part of the release).

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions). — It is, but Mergify only uses the config file on master

[geekosaur]

Naturally, it turns out that Mergify has no way to say "doesn't match regex". I guess there was a reason we didn't have rules for it. (ETA: no, it's just really sensitive to how you write it)

[geekosaur]

The rules I implemented are a hybrid of the master and backport rules:

• 2 reviews required
• no delay between setting the merge label and merging

We should probably iron out what we want the actual rules to be.

[geekosaur]

And while we're thinking about merge rules, should we prevent merging PRs with a blocked: label?

[Mikolaj]

And while we're thinking about merge rules, should we prevent merging PRs with a blocked: label?

If that's not too fiddly, sounds good.

[Mikolaj]

This makes a lot of sense and we can tune it later on if anything proves cumbersome.

[geekosaur]

Waiting on #10136