Faking per-hunk ancestors

One nice feature of three-way merge is that it presents a common ancestor
in the UI for merges. If Monotone switches to Codeville merge, we'd like
to continue to support this feature. The current version of Codeville
merge can't do this at all, but it turns out that the upcoming precise
merge can do it quite well.

We take the section of the weave which both sides of the conflict come
from (between the non-conflicting context lines) and pull out all lines
which are part of the 'common ancestor', and present them in the order
they appear in the weave. The funny thing about this approach is that it
might pull out a common ancestor which never actually happened, but when
that occurs the 'common ancestor' displayed is usually far less confusing
than a real common ancestor would have been, and this is just advisory
information anyway so it doesn't have to conform to mathematical
perfection.

Here's the filtering algorithm: Each line in the shared section will be
either unborn, living, or dead on either side, determine whether to
include it based on this table (lines with a * are included)

uu
ul
ud
lu
ll  *
ld  *
du
dl  *
dd  (see below)

In the dd case, it depends on how the line was deleted. If there's a
shared ancestor of both sides which deleted the line, then it isn't
included. Otherwise, the line is considered to have been deleted after the
shared ancestor, and is included.

Here are some examples:

abcd -> aXcd -> aYcd
abcd -> abPd -> abQd
(aXcd, abQd) -> aRd
(aYcd, abPd) -> aZd

Merging together aRd and aZd will now give a common ancestor of aYQd,
which never actually happened, but is the most reasonable common ancestor
to display.

abcde -> Xbcde
abcde -> abcdY
(Xbcde, abcdY) -> XbPdY
(Xbcde, abcdY) -> XbQdY

Merging XbPdY and XbQdY together will now give a common ancestor of XbcdY,
which also never actually happened, but is again the most reasonable thing
to display.

-Bram