I hate conflicts!!!

I've located the bug that causes this, and it's right smack in the most
complicated commute in the new conflict-handling code.  :(

The trouble is that the input to filterConflictsFL is incorrect in this case,
because we ignore the context of n1, which is problematic when it's a conflict
resolution patch.

I don't (yet) see a solution, and understand that few folks on the nosy list
will follow this, but wanted to write something down lest I forget what I've
figured out.

The problem (as is very common) lies in the fact that we have two "states" to
take into account in this version of the patch theory:  the "tangible"
state--which refers to the actual contents of files and directories--and the
"intangible" state, which refers to the set of patches in the repository.  The
two are interchangeable in the absence of conflicts.  Unfortunately, the
tangible state is the only one we track with our type witnesses, so it's still
easy to introduce bugs in which we get the intangible state wrong--as happens here.

The tangible and intangible states differ only in the case of a conflict
resolution patch, which is a patch that would have conflicted with some changes,
except that those changes have already been made.

Ideally, we'd have a dual type-witness system to track these two states, but
alas, that is not yet in place.  And it might be too tricky to work out in
practice anyhow.

To summarize (and you've been warned, I think, that this message is unlikely to
be comprehensible), when we call

filterConflictsFL p2 n2n1

the trouble is that p2 has in its context some patches that are resolved by a
patch in n2n1, but since n2n1 is stored as a FL Prim, there's no way for
filterConflictsFL to know this.  So we either have to adjust the context of p2
somehow before filtering, or somehow fix the context of n2n1.

Related to this is the fact that we define

n2n1 = n2 +>+ n1

which might actually be wrong at times, if some of the changes in n1 are
resolution patches.  I'm not certain about this.

Anyhow, I think that's all the work on this bug for today.  Hopefully tomorrow
I'll be able to see more clearly.

David