First attempt at doing something about #19

This is a pretty hacky solution to representing content conflicts. Note that content is e.g. the value of a literal, or the name of a method. The children of a node are not part of the content of a node.

Essentially, when two nodes are found to have conflicting content in revisions (more than one piece of content after merging has finished), it's represented as a merge conflict by simply replacing the content with a literal merge conflict. Then, the pretty-printer will just print it out without any fuzz, with newlines and all.

https://github.com/KTH/spork/blob/cec7468f46c42d7e78cebb654f4737e789194bd8/src/main/java/se/kth/spork/merge/spoon/SpoonPcs.java#L307-L347

This works under the assumption that all node contents in Spoon (e.g. literal values and method names and the like) are represented by actual Java String objects in the metamodel. This has so far proven correct, but I may be wrong on that account. It also assumes that each node has at most one piece of content. This may also be incorrect.

A big drawback of this approach is that adjacent conflicts are represented as separate conflicts. Below is an example.

// assume the base revision has this method header
public int add(int a, int b)

// assume the left revision changes it like so
public long adding(int a, int b)

// assume the right revision changes it like so
public double sum(int a, int b)

merging these revisions results in a conflict that looks something like this

public
>>>>>>> LEFT
long
=======
double
<<<<<<< RIGHT
>>>>>>> LEFT
adding
=======
sum
<<<<<<< RIGHT
(int a, int b)

but obviously, a conflict like this would be more desirable

public
>>>>>>> LEFT
long adding
=======
double sum
<<<<<<< RIGHT
(int a, int b)

This could be solved with text processing after the fact, or better yet with an entirely different approach to showing content conflicts.