tracking implicit rollback

I'm working on full-blown precise cdv-merge now, and it turns out some
details of implicit rollback are non-trivial.

The nice properties of the weave reduce implicit rollback to versioning a
single bit of information: whether a single line is present or not. The
algorithm for merging revisions must be able to take any two revisions and
merge them cleanly (checking for conflicts is done by combining
information from multiple lines, so there's no need to worry about it at
this level).

Each revision in the history can have a marker saying 'the value at this
point must be X', where X is either 0 or 1, which overrides whatever value
that revision might have clean merged to from its ancestors. The root
revision's value is 0.

Here are three criteria which the merge algorithm must meet, I don't know
if they're sufficient to unambiguously define the value in every case, but
I believe they're necessary

(1) if several revisions are merged together, the result must be the same
regardless of the order they weree merged in

(2) if B is a descendant of A and neither B nor A declare what the value
should be on that revision directly, then if declaring that A must have
the value opposite what it currently does would flip B's value, then
declaring that A must have the opposite of its current value and that B
must have its current value must result in all descendants of B having the
same values they had before

(3) if X is a descendant of a set of ancestors and has the opposite value
of the clean merge of all of those ancestors, then merging X with a clean
merge of all of the ancestors must result in the same value as X has.

I have a technique for doing merges which I *think* accomplishes all of
these, but I had to patch it enough times that I don't really trust it for
truly obscure cases, and I'd much rather have a technique which was
derived directly from the above criteria with a proof of correctness.

-Bram