Make diff line matching more robust

[jcansdale]

This PR matches diff lines based on their original line number and content.

• Diff lines can be matched based on a single line (multiple lines of context aren't required)
• Lines can be inserted between and near to comments without them vanishing

Fixes #1052

[grokys]

There are problems with this approach. For example, I created this PR: grokys/PullRequestSandbox#29

As you can see, I added a comment on line 22, but in VS with this PR, this is showing up on line 15:

[jcansdale]

@grokys Well spotted. 😄 I've been wondering about how to make it more robust. Could you try this latest push. It will match using all available context lines before falling back to matching using the original line number.

Still not perfect, but I wonder if this will end up being about getting the balance right (false positives vs false negatives).

[grokys]

It now shows the unedited file with the comments in the correct place, but when I delete the Guard.NotNull as the comment suggests, the comment jumps to line 15 again.

[jcansdale]

From @grokys on the Slack:

i think something like that will give much better results
but obviously, it's more involved which is why i was punting it until we've got the basic stuff working...
tbh i think the only _real_ way to do it would be to track the position of the comments as edits are made and store them locally
then use an algorithm like the above to match comments if the file is e.g. edited outside VS
we also need a "outdated" visual state to show that the comment may no longer be valid
to me it feels like a separate minor release

I'm going to push a version that fixes the original issue. It was trying to match 5 lines of context when the diff only had 3.

[jcansdale]

I've just pushed more of a point fix that should resolve just this issue. Hopefully 3rd time's a charm? 😉

[grokys]

LGTM!

[jcansdale]

I've done some more testing on .com this seems to behave very similarly. Sometimes .com requires less than 5 lines of context, but when I noticed this the API returned only 4 lines so the extension actually behaved in a similar way.