Optimize locking a tuple already locked by another subxact

The original coding tried to avoid locking tuples twice when other
subtransactions of the current top transaction already held the
requested lock, but the coding was bogus and some cases were slow, as
reported by Oskari Saarenmaa in bug #8470.

In order to make it work, HeapTupleSatisfiesUpdate is changed so that it
always returns HeapTupleBeingUpdated when the tuple is locked, even if
the locker is the current transaction or another subtransaction of the
current transaction; that case previously returned HeapTupleMayBeUpdated
and was handled specially by callers, but it turns out to be less
error-prone to instead have them check whether the reported lock is held
by the current transaction.  That way, more optimizations are enabled in
compute_new_xmax_infomask.

The difference in performance between 9.2 and patched 9.3 is now more
reasonable -- in my measurements it is indistinguishable from noise in
the test case supplied in bug #8470 (instead of 17x worse), and up to 2x
worse in a tweaked version (instead of 56x worse).
Skip looking up very old LOCK_ONLY MultiXactIds

Commit 0ac5ad5134f2 removed an optimization in multixact.c that skipped
fetching members of MultiXactId that were older than our
OldestVisibleMXactId value.  The reason this was removed is that it is
possible for multis that contain updates to be older than that value.
However, if the caller is certain that the multi does not contain an
update (because the infomask bits say so), it can pass this info down to
GetMultiXactIdMembers, enabling it to use the old optimization.

Pointed out by Andres Freund in 20131121200517.GM7240@alap2.anarazel.de