Handle diff3-style merge correctly

[katemihalikova]

Fixes pprice/vscode-better-merge#23.

I'm using merge.conflictStyle = diff3 git setting, but the style (Current/Common ancestors/Incoming) is not supported in VS Code. In the new merge extension (#27150), the Common ancestors block is merged together with the Current block. This PR adds that support. As diff3 is a superset of the default git conflict style, I've modified the original algorithm to support both styles. The same fix was also proposed by @spiffytech in the original issue.

[mention-bot]

@katemihalikova, thanks for your PR! By analyzing the history of the files in this pull request, we identified @pprice to be a potential reviewer.

[msftclas]

@katemihalikova,
Thanks for having already signed the Contribution License Agreement. Your agreement has not been validated yet. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

[sandy081]

@kieferrm Not sure who owns the merge extension, hence assigning this to you. Please re-assign it to the right person.

Thanks.

[pprice]

🎉 Thank you @katemihalikova LGTM! @chrmarti / @kieferrm can give final approval.

I tested Kate's fork locally, and everything appears to be working great.

[pprice]

@kieferrm, @chrmarti: We should probably add a new theme color from common ancestor blocks. I'd be in favor of coloring them at some point.

[pprice]

Nit; might as well mark commonAncestors as optional e.g. commonAncestors?

[katemihalikova]

• Marked as optional

[pprice]

Nit; Could be condensed to

const tokenAfterCurrentBlock = scanned.commonAncestors || scanned.splitter; 

[katemihalikova]

• Condensed

[pprice]

If, for some reason, we ended up with:

<<<<<<< HEAD
Foo
||||||| common
foo
||||||| common
fooo
=======
blah
>>>>>>> incoming

We will end up extending the "current" content over the first merge ancestor block. If we encounter two blocks of ||||||| I think there are two thing we could do:

• Favorable: Don't overwrite currentConflict.commonAncestors, just leave it with the first occurrence, this way the current content block will span the correct range. (e.g. else if (currentConflict && !currentConflict.commonAncestors && line.text.startsWith(commonAncestorsMarker))
• Break out of scanning (like we do if we encounter a start marker before an end marker), so we don't provide any decoration if we are unsure what to do.

FWIW I think this is also true of existing ======= scanning...

[katemihalikova]

• Incorporated the first solution for both markers, now we are using just the first token of each type, just like TypeScript does.

[katemihalikova]

I've resolved the conflict.

[chrmarti]

Thanks for your contribution @katemihalikova.

I will add the workbench colors on top. One corner case is with multiple common ancestors where these have only a single header decoration. With some background colors applied this looks like:

Would adding one header and one content decoration for each common ancestor improve on this?

[katemihalikova]

Yeah that makes sense, I'll add it.

[katemihalikova]

@chrmarti The last commit added support for multiple common ancestors blocks:

(background colors are not included)

[chrmarti]

Thanks @katemihalikova !