[READY] Add support codeAction/resolve requests

[bstaletic]

So... We advertise that we can handle CodeActions that are either missing an edit or a command (or both). The server chooses whether it supports either of the two. If it does, it advertises itself as a "code action resolve provider".

For servers that are code action resolve providers:

• If either edit or command is missing, we need to try resolving the code action via codeAction/resolve.
  • Unless we actually got a LSP Command, in which case codeAction/resove is skipped.
• After resolving it that way we have a CodeAction in one of these forms:
  • A LSP Command
  • A LSP CodeAction with only an edit.
  • A LSP CodeAction with only a command.
  • A LSP CodeAction with both an edit and a command.
• Edits are WorkspaceEdits and can easily be converted into ycmd FixIts.
• Commands are to be executed, yielding ApplyEdits. A single ApplyEdit can be converted into a ycmd FixIt.

For servers that are not code action resolve providers, the steps are the same, but we skip the codeAction/resolve route.

One thing missing is properly defined handling of fixit resolutions that yield multiple fixits. That can happen in a few ways:

• On /resolve_fixit, by a LSP command yielding multiple ApplyEdits.
• When eagerly resolving a fixit, again by a LSP command yielding multiple ApplyEdits.
• Even if all commands always yield a single ApplyEdit, if a CodeAction has both an edit and a command, that's again two fixits.

The first two above don't seem to be used by any server ever. The LSP specs nudges servers away from doing that, but no promises. We are still not supporting any scenario where resolving a single fixit results in more than one fixit.

Another scenario that does not seem to happen:

• The server is a code action resove provider.
• The received CodeAction has neither an edit nor a command.
• After resolving, we get only a command.
• We then need to execute the command and collect ApplyEdits.

In practice, such code actions resolve to a CodeAction containing an edit.

As for the ycmd<->client side of things... it's a bit ugly on the ycmd side, but we're completely preserving the API, so clients do not need to change a thing.

Previously, clients got { 'fixits': [ { 'command': LSPCommand ... } ] } for unresolved fixits. However, we have not given any guarantees about the value of 'command'. We have only said that it should be returned to ycmd for the purposes of /resolve_fixit. With this pull request, we need to pass the entire CodeAction, but we're still putting it in the command key.

---

This change is 

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 94.28571% with 2 lines in your changes missing coverage. Please review.

Project coverage is 95.90%. Comparing base (6f1f4f8) to head (a5f4086). Report is 4 commits behind head on master.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1754 +/- ## ========================================== + Coverage 95.87% 95.90% +0.03% ========================================== Files 84 84 Lines 8437 8450 +13 Branches 163 163 ========================================== + Hits 8089 8104 +15 + Misses 298 296 -2 Partials 50 50 ```

[bstaletic]

I'm finally happy with this pull request. Codecov says that I should have covered the changes better, but the overall coverage is up.

[mergify[bot]]

Thanks for sending a PR!