Fix branch update race causing review breakage

In rare cases, two users pushing conflicting updates of a review branch
at the same time could trigger concurrent invocations of Critic's hook,
that could both accept the update, and add all of the added commits to
the review.  This then lead to a review with an invalid set of commits
(and a "invalid commit-set: multiple heads" crash when loading the review
front-page.)

Git would inevitably reject one of the updates, since the actual ref
updating is "safe" (the ref is locked, and then updated with a check that
it still has the same value as it did when the whole updating process
started.)

Fix this using "SELECT ... FOR UPDATE" when fetching each updated
branch's row from the database.  This row contains the 'head' value,
which we use to validate the update (IOW check that the old value from
Git matches what we think it should be.)  By locking the row, we force
the "second" call of Critic's hook to wait until the first call has
completed and has updated the branch's row with the new head value.

Or, rather, since the second call would then most likely reject the
update ("wrong old value") we might as well not wait (using "FOR UPDATE
NOWAIT") and instead fail immediately if the row is locked.  We can then
provide a more to-the-point error message (since "wrong old value"
typically indicates that the repository and the database are out-of-sync,
and produces a much more serious sounding error message.)