Add --upgrade-after argument and drop 002-late-upgrade test group

Late upgrading is sometimes absolutely necessary testing, but the model
implemented by the 002-late-upgrade group is inherently inflexible and
impractical.  What tests need to run before the upgrade, and what to test
after the upgrade, depends entirely on the upgrade and the particular
migration scripts it will run, and isn't practical to "hard-code" with a
test group like 002-late-upgrade.  Also, an extra group adds significant
cost to testing, often to little or no use.

The new --upgrade-after means any set of tests can run, and the upgrade
can be "inserted" anywhere in that set of tests.  For now, this will only
be useful for manual testing, but it would be possible to add some
mechanism by which a commit (via some checked in control file) can declare
useful test runs, that the automatic testing system could use to run
additional custom tests when testing that particular commit.
Clean up handling of equivalent merges and replayed rebases

When performing a move rebase, we will either create an "equivalent merge"
(for a fast-forward rebase) or a "replayed rebase" (otherwise.)  In the
former case, we'd update the review rebase's "old head" to point to the
equivalent merge, as if it had been pushed to the review before the rebase.
A replayed rebase wasn't directly recorded in the database at all, instead
its existence was deduced from there being a changeset added to the review
of type "conflicts" whose child commit was the new head of the rebase.

This was generally messy, and error-prone to work with.

Instead of all this, add two explicit columns to the reviewrebases table,
equivalent_merge and replayed_rebase, and set the appropriate one to point
to the generated commit when performing a rebase.  Adjust code elsewhere
to use the values of these columns.