Correct generate rename code action in LSP

[Cosifne]

If a document is renamed, using Document.Rename
The document would still have the same document Id.
In this case, the document is considered as InfoChange

In LSP we only generate text edits to the client, and this would make things like 'Rename file to match the type' not working in LSP

[jasonmalinowski]

This is probably going to throw exceptions around additional files if we had a rename of those; the test also potentially looks incomplete as I'm not sure it's missing an assert. Should be easy to fix though.

[jasonmalinowski]

Should we have filtered out this sort of code action earlier rather than bailing here? Because this would mean we will show the action but invoking it will do nothing? I see this pattern is widely used so I'd rather take this PR than nothing at all, but still wondering if we should be making further changes here.

[Cosifne]

This pattern is introduced by Sam to overcome the cases when VS doesn't support the client's capabilities.

This seems like we need to ask each refactoring provide/code fixer to give hints about the kind of operation it is going to perform when the code action is computed. So we can filter the unsupported code actions before the changes are computed.
It sounds like a bigger change, but unrelated to this PR.

Tag @dibarbet , @sharwell also maybe @CyrusNajmabadi
Do we want to create a work item for this?