Add table for keeping track of remotes that "pushes" updates

If a remote has a post-update hook that talks to the branchtrackerhook
service, it's rather unnecessary to poll for updates to tracked branches
in that remote every hour.  (Or at all, really.)

With this fix, tracked branches in any remote listed in the 'knownremotes'
table (with the 'pushing' flag/column set to TRUE) are polled for updates
once a week instead of once an hour.  Remotes are added to the table
automatically whenever they actually push updates.
Normalize empty (review) filter path to "/"

Move normalization into reviewing.filters.sanitizePath() instead of doing
it client-side.  Also check validity of wildcards in review filter paths,
and remove incorrect client-side restriction on wildcard characters in
review filter paths.

Also strip leading "/" from paths.
Fix "common path prefix" calculation

If a path was a prefix of the common prefix so far, but shorter, the
common prefix wasn't shortened as it ought to be.
Fix crash on rebased review in some (unknown) circumstances
Tune filter ranking slightly

When counting the number of forward slashes in a filter path, do not
include slashes that follow "**", since "**/" matches zero or more path
components, and thus might not actually represent a slash in the final
path.

This means "**/*.txt" is ranked below (less specific) than "foo.txt"
which intuitively makes sense.  Before this adjustment, it would have
been ranked above it on account of it containing more forward slashes.
Fix crash when rendering certain addressed issues

If an issue is marked as addressed by a non-fast-forward rebase, show
the original diff (with the comment on the right-hand side) instead of
the diff of the commit that addressed it.  The normal way of displaying
an addressed issue assumes that the issue is present in the left-hand
side of the (direct) diff of the commit that addressed the issue, but
this is usually not true in this particular case.
On /home, count matched paths using right user's (other) filters

If user Alice loaded /home?user=bob, the paths matched by each of Bob's
filters was calculated taking Alice's filters into account rather than
Bob's, leading to incorrect results.
Use page.utils.generateRepositorySelect() on /branches

Also optimize rendering making fewer database queries.

Also rewrite the implementation almost completely.  :-)  (It was designed
so that parts of it could be reused by other pages, but there are no
other pages that list branches, so it was just unnecessary complexity.)
Support retroactively applying global filters in review

It is possible to create a review that ignores global filters and thus
has reviewers and watchers only assigned via review filters (or manual
assignment.)  One possible use-case for this feature is to create a
review quietly, do some things in it, and then have regular reviewers
assigned later on, in which case it's good if it is possible to make
global filters apply in such a review retroactively.
Improve support for deleting reviews

There is no UI for deleting reviews, but it can be done using a direct
connection to the database, and, in rare cases, makes sense to do.

To better support this, add "ON DELETE SET NULL" to some foreign key
constraints referencing the 'reviews' table, and add an index to the
'reviewmessageids' table (which can be rather huge) so that its "ON
DELETE CASCADE" foreign key constraint is less expensive to apply.
Include timestamp in news item display
Extend watchdog service to (optionally) monitor system load

If limits on 1, 5 and/or 15 minute load averages are configured, the
watchdog service sends emails to the system administrator when they are
exceeded.
Optimize generation of common repository select

The database query for "repositories in which the user is associated to
any reviews" was quite expensive, doing full table scans on both 'reviews'
and 'branches' (with no obvious way to make it stop.)  In practice, since
repositories where the user has any filters are already included, most of
those repositories will typically also already be included.  Simplifiy
this query to limit its search to reviews owned by the user instead (this
is also unlikely to add any extra repositories in practice.)
Fix issue where direct pushes to tracking reviews were allowed

Direct pushes to review branches that track branches in other repositories
are supposed to be rejected.  But since the branch tracker service uses
"git push" to update branches too, an exception needs to be made.  The
exception was implemented by checking if the user was the Critic system
user.

This however is not conclusive.  Extensions, for instance, run as the
Critic system user, so "git push" executed by an extension would still be
allowed, incorrectly.

This commit improves the exception by adding support for passing "flags"
from the pushing Git process to the githook service via the $CRITIC_FLAGS
environment variable (valid only if the Critic system user is pushing.)
This mechanism is used to pass a flag saying that the push is used to
update a given tracked branch.
Improve detection of whether comments are active

The logic for determining whether a comment is active or not ("present in
the commit at the tip of the branch") used "commit has no children in the
set of relevant commits" as the criterion for determining this.  It is
however possible to achieve a sort of cycle in the commit-set, in which
case this is not true for any commit, and no comments can then be active.

One way to achieve such a cycle is to have a review containing the commits
A, B and C, where C reverts B, and then do a history rewrite rebase back
to A.  A is then the tip of the branch, but still has children in the
commit-set.  In this situation, a comment present in A should be active,
even if changes in B/C touch the lines.

Fix by changing the logic to actually explicitly detect that the comment
is present in the commit at the tip of the branch.  Sometimes this commit
can be found as "self.review.branch.head", but notable can't when commits
are added to a review, since "self.review.branch.head" won't have been
updated yet.  In the latter case, use the head of the set of added commits
instead.
Tweak basic error handling code

Let request.DisplayMessage inherit base.Error (instead of Exception.)

Also return OperationError objects from Operation.__call__() instead of
re-raising them.

Also remove some obsolete error handling around the call to operation
functions; they never raise anything since Operation.__call__() (now)
catches everything and translates any errors into (returned)
OperationError or OperationFailure objects.

Also convert some "except A, B" => "except A as B".
Fix minor typo in tutorial
Refuse to create empty (or white-space only) comments
Improve error message when Operation() triggers 404 errors

Usually indicates out-of-sync server-side and client-side, which might
be helped by a simple reload, or, if an extension is involved, an update
of the extension.  Say as much in the error dialog.

Displaying the HTML source of the standard 404 page in an error dialog
is not exactly helpful.
Sanity-check selected repository and remote in /fetchremotebranch

If any repository other than the selected one already tracks a branch in
the remote, the remote is probably not the right one for the selected
repository, and importing branches from it is not a good idea, or what
the user really wants to do.