Need sanity-bot to police cherry-picks; only stable -> LTS allowed.

We plan, once 5.7 closes, to switch to cherry-picking from stable (5.8 and later) to LTS (5.6).
In support of that, we need sanity-bot to grumble about any cherry-pick that isn't stable -> LTS.
In particular, the "stable" to check against isn't the local repo's stable (which may be where the developer prepared the commit, with a different sha1 than the one gerrit cherry-picked it to when accepting it into public stable); we need to check against the stable of gerrit (falling back on origin if no remote appears to be gerrit).

Things to check (some of these may also be apt for reverts):

• only stable -> LTS (in released modules)
• prior sha1 names a commit on some branch known upstream
• prior sha1's commit has a Reviewed-By line
• new Change-Id, if present, matches that of the prior sha1

The sanity-bot already has code to recognise cherry-picks (and reverts); so we can easily pick up the source sha1 and use git branch -r --contains to find the remote branches that contain it.

For now I can cope with hard-coding LTS as 5.6, although I'd prefer to avoid doing so. However, we need some sensible way to know what stable is. The script could use heuristics (e.g. git tag | grep '^v(.*)\.0$' and pick the highest-numbered $1); or we could have a file in qtrepotools/config/ that tells us the mapping from abstract names (release, stable, LTS) to actual branch names (5.9, 5.8, 5.6). The latter is more robust but requires an update each time we close old stable and assign a new stable.

Given stable's name, it's easy enough to see if gerrit's version of it shows up in the git branch -r --contains output for our source sha1.
Somewhat trickier is determining whether the destination of the pick is LTS, as we should allow a topic branch off LTS. We can ask for the merge-base of HEAD and LTS; if its git branch -r --contains includes any other \d\.\d branches then I think we can fairly say we're not "on LTS". (We may just be on an old branch off LTS; but a git fetch of LTS and rebase onto it can fix that.)

Determining the remote to use for gerrit needs some care, too.

git remote -v | grep 'codereview\.qt-project\.org'

can give us a list of candidates; if one of these is called gerrit, take it; else origin; else first named. If we get no matches, use origin (it's hopefully at least "upstream" towards gerrit). If there's no origin, we can't do this check; the developer has a weird set-up; let them discover their error when pushing to gerrit (where, I trust, sanity-bot is run in an environment that does have a sensible remote called gerrit or origin).

We also need to suppress the "stable -> LTS" check when not in a releasy module (i.e. one with the usual branches).
It may be sensible to suppress the stable -> LTS check also when picking between topic branches; don't harass developers toying with local commit histories.