Implement textDocument/prepareRename for better rename experience

[dibarbet]

Resolves dotnet/vscode-csharp#6643

Why

Two benefits of implementing prepare rename

1. The UX is better when an item cannot be renamed (see gifs below)
2. It allows us to play nicer with other extensions that implement rename in different contexts.

Before this change - rename on invalid identifier

After this change - rename on invalid identifier

[CyrusNajmabadi]

curious what 'default' means in this context.

[dibarbet]

Default means default rename behavior. Prepare allows you to specify a special range, but we don't use that.

[CyrusNajmabadi]

thanks! what is an example of a 'special range'? (just for my understanding).

[dibarbet]

The range to rename - see the docs on the return value here https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_prepareRename

[davidwengier]

Looked into piggy backing off this to add support to Razor, and FYI this will break rename in VS if the handler lights up there (ie, when LSP is turned on): https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1914930

[dibarbet]

@davidwengier it sounds like if I merge this it will break rename in Razor, is that correct? Or will it continue working because Razor doesn't call Roslyn's prepare rename?

[davidwengier]

It's cool, you can merge. We don't advertise prepare rename support, so they won't call us, and we won't call you. In fact, if we do want to support we can workaround the client issue in Razor, by translating your response into a range response, so we're not blocked either way.