Properly fix backport MRs breaking release pipelines

Currently there's a race when landing a MR to a branch and doing a straight backport from that branch to other branches.

Consider this scenario:

1. a MR is opened against apertis/v2023dev1
2. the MR is reviewed normally and everything is ok
3. the MR is landed while the CI system is quite loaded
4. a developer quickly creates a new MR from apertis/v2023dev1 to apertis/v2022 to backport the just-landed fixes
5. the CI finally catches up and notices the new commits on the apertis/v2023dev1 branch
6. since there's an open MR from apertis/v2023dev1 to apertis/v2022 the CI system will not create a pipeline for the apertis/v2023dev1 branch, and will only run the one in the MR context targeting apertis/v2022

The undesirable result is that the changes landed on apertis/v2023dev1 do not get uploaded, since the branch pipeline meant to do that is skipped.

The run_on_mr_xor_branch_rule condition is meant to:

1. run pipelines in MR context to reliably derive the target release from the target branch to e.g. use the v2021 docker images when targeting apertis/v2021-security
2. avoid running two pipelines when one is enough and the other would fail anyway, e.g. trying to build a v2021 package using a v2023dev1 docker image

We can opt $OSNAME/* branches out of that because neither goals actually apply: the pipeline knowns the right target release by definition and we actually want to run both pipelines in the different contexts with different target releases.

!228 (merged) was intended to fix this, but instead it resulted in backport MRs uploading their CI results to the release repos (!231 (merged)). Instead, just don't block release pipelines from running when a backport MR is open.

https://phabricator.apertis.org/T7890