Fix the ArgumentOutOfRangeException in inline rename

[Cosifne]

Fix two places that might cause ArgumentOutOfRange exception in inline rename during my testing.

[Cosifne]

The second place causes ArugmentOutofRangeException.
When the identifier in the text box gets changed, it would update the text selection in the editor.

This might cause an Exception because text selection might also get changed when the replacement text changes.
(Like, if you type F when rename Field123, the replacement text is F, and text selection becomes zero length)
We are still using a out-off date state https://sourceroslyn.io/#Microsoft.CodeAnalysis.EditorFeatures/InlineRename/AbstractInlineRenameUndoManager.cs,143 to update the selection in the editor.

[Cosifne]

This is triggered by the binding from the UI. And we only know replacement text gets changed
IMO we should not try to update the selection at this point. Later it would be updated by another event handler of the control

roslyn/src/EditorFeatures/Core.Wpf/InlineRename/UI/Adornment/RenameFlyout.xaml.cs

Line 210 in d7e010b

private void IdentifierTextBox_SelectionChanged(object sender, RoutedEventArgs e)

[ryzngard]

Definitely agree with this. It's actually kind of odd that selection was being changed by the old style. There's probably some cases I can't think of where that's required.

[Cosifne]

The story:
This is causing #68880.
Given a code

class Bar 
{
    // Some code
    public int Field123;
}

Field123 has length. Suppose the total length of the document is 100.
Field123 would be [91, 98]. When type F after invoking the new inline rename.
It would

1. Delete all the text of Field123.
2. Insert F

After step 1, the document shrinks, its length becomes 92. Here _referenceSpanToLinkedRenameSpanMap.Keys stores the original text span in the document, so AreAllReferenceSpansMappable would return false, because s.End <= _subjectBuffer.CurrentSnapshot.Length is not true. (s.end is 98, the total length of the document is 92)

This doesn't cause problems in the old rename UI. Because in that case we directly edit the text in the editor. But in the new UI, all the text edit is propagated from the text check box to the editor. In any case, if this text edit is filter out, it would cause the out-off sync between the editor and inline rename check box, resulting exception.

[Cosifne]

This method originates from #9208 and it feels like the old workaround is causing problems in the new UI. (I have verified it's still a problem today)
From my understanding, it means in the legacy razor editor, text in @model might not be in the view yet.
If we use the tracking span instead here. At start point, the tracking span should be equal to the span here. (key and value of the dictionary should be pointed to the same thing) So the wrong case would be filtered. Since razor document doesn't get changed in rename session, the tracking span would stay the same all the time. So we don't regress the old behavior.

In normal editor case, because tracking span grows/shrink with the text edit won't be filtered.

[Cosifne]

Verified in legacy razor editor (use new inline rename UI):

Verified in new razor editor(use new inline rename UI):

[Cosifne]

Verified in new razor editor (Use old inline rename UI):

Verified in legacy razor editor (Use old inline

rename UI):

[Cosifne]

Also tag @jasonmalinowski if you interested in reviewing this

[Cosifne]

Alright, @jasonmalinowski I will check this in since it is blocking me from fixing another rename bug. If you have any worries we can sync in following PR.