Fix #21

First step toward #20

Tests current implementation for #19

This is a big PR with a lot of changes that aim to support handling of structural conflicts. It works in a few steps.

• During the core 3DM merge, structural conflicts are registered with the delta object.

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/merge/TdmMerge.java#L59

• During interpretation from Pcs to Spoon tree, both sides of a conflict is added to the merge tree, with metadata on the tree nodes saying which side of the conflict they belong to.
  • Note that this relies on the assumptions that a) structural conflicts can only occur in list-like syntactic environments (e.g. statement list), and b) that structural conflicts can only occur among ordered elements.

Detect start of conflict

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/merge/spoon/SpoonPcs.java#L116-L121

Traverse the conflict and its children

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/merge/spoon/SpoonPcs.java#L141-L168

Add metadata to conflict starts/ends

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/merge/spoon/SpoonPcs.java#L278-L306

• During pretty-printing, the printer detects the conflict markers and prints appropriate start/mid/end conflict markers

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/cli/SporkPrettyPrinter.java#L25-L67

An important detail

A super important detail is that the left/right match is done only top-down.

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/merge/spoon/Spoon3dmMerge.java#L66

https://github.com/KTH/spork/blob/deddea7e40b9cf3702610c43c093c2ed1ad3bf94/src/main/java/se/kth/spork/merge/spoon/Spoon3dmMerge.java#L258-L262

This means that conflicts become less granular than they could be, but in my limited testing they've been made much more comprehensible this way, and it also eliminates the problem of nested conflicts, which I really don't know how to represent textually. Although high granularity may sound awesome on paper, it can get to a point where there's just so much visual noise from the conflict markers that a rougher separation is better. I think that I will have to do some further experimentation here, but initially I think it's a good idea.

A bit hacky?

Yes, this is a little bit hacky, but there's a large benefit of handling structural conflicts this way, namely that no special Spoon nodes need to be implemented. The alternative would really be to have some special "conflict" nodes, e.g. a CtStatementConflict, which is a CtStatment in and of itself, but also has a left and right revision of statement lists. That may be a better way moving forward, but for now I think solution will be all right for prototyping purposes.