[WIP/RFC] Allow code actions containing an edit and a command

[bstaletic]

Fixes #1692

WIP, because still no response to microsoft/language-server-protocol#2015
But also tests.
Previously, we could not handle two cases:

• code action containing an edit and a command
• commands producing multiple edits.

This pull request currently aims at the former. Manually tested with the Dart server and everything worked fine.

Design

LSP

Assuming we get a code action with an edit and a command, the client should do the following:

1. Apply the edit.
2. Send didChange notification.
3. Execute the command.

Step 3 is still pretty much dark magic.

ycmd

Current implementation, when faced with "mixed" code actions does:

1. Convert the edit to a ycmd FixIt, but setting a new property, keep_going to True.
2. Stores the command for later.
3. Responds to the client with that one FixIt.
4. Once a client decides to apply a FixIt with keep_going set, after applying, it should ask ycmd for the next FixIt in the chain.
   4.1. I couldn't figure out a better way than to introduce a new route - /next_fixit
5. Upon receiving a /next_fixit request, ycmd will execute the previously stored command (step 2).

Obviously, /next_fixit and keep_going are prone to bikeshedding.
I'm more concerned whether the whole idea about storing the command for later is a good approach.
It works... but only because :YcmCompleter FixIt is synchronous. If it weren't, there'd be room for error.

---

This change is 

[puremourning]

I'm more concerned whether the whole idea about storing the command for later is a good approach.

honestly, I don't love it. I would prefer to send the "next list" on the response as opaque data and have YCM send it back to us if necessary.

All In all, I'm not convinced that we need to have this complexity, given that there are still only "suggestions" that anyone will ever actually do this in a server. I would be tempted to wait until something actually uses it and see how it breaks in practice..

WDYT?

[bstaletic]

I would prefer to send the "next list" on the response as opaque data and have YCM send it back to us if necessary.

Let me see if I got your idea right.
Since this pull request only implements the case where we get an edit and a command (i.e. still no support for multiple applyEdits from a single command), we actually know the whole chain of fixits that we want to apply.
Therefore we can do away with the keep_going thing.
On one hand, that does seem more robust.
On the other, isn't that the opposite of what we are doing with completionItem/resolve, where YCM only gets "some number" and not the whole LSP completion item?

I would be tempted to wait until something actually uses it and see how it breaks in practice..

Dart language server already does this.

Reviewable status: 0 of 2 LGTMs obtained