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

[bstaletic]

Fixes #1692

WIP, because still no response to https://github.com/microsoft/language-server-protocol/issues/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?