We recently moved the $commits variable out of a "subshell in a
herestring", let's do the same for the list of branches, where errors
would be silently swallowed as well.

Also reformat the expressions slightly, we have enough line-length.

(cherry picked from commit e2a3792)
(cherry picked from commit 92ff241)

(cherry picked from commit 6cf5f9e)
(cherry picked from commit c4b8c13)

The default is to checkout a contributors fork as "origin", thus the
NixOS/nixpkgs remote is most likely named differently. But not everybody
keeps their fork's main branches up-to-date all the time. Thus the
script would fail locally.

(cherry picked from commit 2fea2bb)
(cherry picked from commit 63b1cc8)

In a small terminal window this would just stop running after each
commit until you exit the pager. That's not what we want when running it
locally.

(cherry picked from commit 245b1c1)
(cherry picked from commit 7f5b7cd)

Using a `tree:0` filter instead of `blob:none` reduces the checkout time
from over 3 minutes to about 45 seconds. The required trees/blobs will
then be fetched on-demand.

This on-demand fetching creates additional output for `git range-diff`
on stderr, so we hide that. This only happens the first time it's run,
so we don't need to adjust the other calls - which will still return any
real errors, should they happen.

(cherry picked from commit e575364)
(cherry picked from commit 331bbc4)

…python-updates

Those are protected branches, which can't be force pushed to - so the
commits will remain. Thus, we can also backport from them.

(cherry picked from commit ea636d1)
(cherry picked from commit 5f23ca9)

This makes the job significantly faster when the commit can't be found
on master or staging directly. Before this change, the script would have
had to iterate through 20+ release branches before finding the latest
one. With lazy fetching for git enabled, this would take a few minutes.

(cherry picked from commit a9b718b)
(cherry picked from commit bcf8f3f)

When cherry-picking without -x or not cherry-picking at all, the
check-cherry-picks job would usually remain green. This is annoying to
deal with for reviewers, because "all green" still needs attention -
have all commits been cherry-picked properly?

If a commit was not cherry-picked correctly, either without -x or not at
all, because it's a genuine commit to begin with, the reviewers
attention is required anyway. Thus we can also let the job fail in this
case.

(cherry picked from commit dfaefc0)
(cherry picked from commit d630bf4)