precise codeville-merge reference now available

I've finished a reference implementation of precise codeville merge, you
can get it here -

http://bitconjurer.org/merge.py

The external API is to call new_file_state(), then use current(),
conflict(), mash() and resolve() on the result. current() returns the
current state, as you'd expect. conflict() gives the result of merging two
versions together, possibly with conflict sections. mash() shoves two
versions together without checking for conflicts, and resolve() forces the
file to look like a given series of lines. Generally you call resolve()
right after calling mash().

Big features in this code are history-aware merge (duh) and implicit
rollback. If you have been modifying some code for a while and decide that
your changes suck, simply alter the code to look exactly like it did
before your changes, and it will thereafter merge as if the intermediary
changes had never happened in the first place. This is an important
feature for when one side of a merge conflict wins, and is quite cool on
its own merits. Surprisingly, I was able to figure out an implicit
rollback algorithm which is quite robust, so you can use it with
confidence.

Things missing from this code -

* performance is comically bad. Some big improvements are quite easy,
remember this is a reference implementation. In particular, the calls to
.insert() can be optimized out so that that's a linear rather than a
quadratic operation

* filename rollback isn't worked out yet. This code only handles file
contents, not names and parents. I don't expect rollback of names to be
difficult, but I haven't worked it out yet.

* per-hunk common ancestors are missing. This is mostly because I'm not
sure how to do them. The trick is figuring out a
is_common_ancestor_living() function for LivingStatus. If anybody figures
out how to do that, I'll happily put it in I might figure it out myself
in not too long if nobody else does.

* dynamic line ordering in the weave isn't supported. It would be really
nice to be able to alter line orderings based on later resolutions. That
one is an interesting problem, and I don't have immediate plans to do it.

I worked out how to do add convergence to this code, but it turns out that
there's a broken case. In the case where one side applies then un-applies
a patch and another side just applies the patch, then according to
convergence both applications should be the same, so the un-application
should win. But by the rollback principle the side which did the
un-application had net no change, so the side with the single patch
application should win.

I think that rollback is a much more important and coherent feature than
patch convergence, so I removeed convergence. To add convergence, just
modify set_living() so that it always uses a fixed value for the key in
the new override entry when overriding the root instead of the current
revision.

Whether this problem is a death knell for convergence or a fixable
problem, I'm not sure.

-Bram