Add CodeAction class

[mjbvz]

VS Code 1.20 adds a new CodeAction type that captures additional information about codeactions:

• https://github.com/Microsoft/vscode/blob/b5e2d0a6bcbae4f71099715dc813239d21975eb5/src/vs/vscode.d.ts#L1897
• https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_20.md#codeactionprovider-improvements

This new type is used by several new product features such as the Refactor command and the editor.action.codeAction command. It should also be supported in the LSP for code action provides

[yaohaizh]

Second this. @aeschli

Current, the lsp CodeAction return a list of Command. It is hard to differentiate these commands. In test cases, we need do some filter based on the commands.

[gorkem]

+1
I think the WorkspaceEdit field is also an improvement on the references object. Most code actions are just workspace edits and some LSPs are doing a round trip for no good reason other than specification's short comings.

[mickaelistria]

Seems very similar to proposal in #178

[dbaeumer]

See also the discussion in #432. We should work on this sooner than later since it will make things a lot easier to understand when it comes to commands and code actions.

[rcjsuen]

New OrganizeImports CodeActionKind being considered, see microsoft/vscode#47845.

[mjbvz]

I just merged in the OrganizeImports addition from microsoft/vscode#47850. From the API perspective, all it did was add a new constant.

I'd like to get other extensions that have their own organize imports (such as java) to try to migrate over to using a code action instead. This is blocked until we have basic support for a CodeAction class in the LSP

[mickaelistria]

I would like to work on this, however I've got some preliminary questions:
Does the proposal for the spec have to follow the current class in VSCode? I'm not convinced we need to specify the codeActionKind from 1st round, and I also find more correct for the protocol to clearly use Command|WorkspaceEdit explicitly instead of having 2 distinct field and a comment saying they're exclusive.
Also, should the protocol add some client/server capability to declare what kind of codeActions results are expected/supported (current command-only as default value, codeAction class as an option)? Or can we just move it forward and let clients implement some tricks for backward compatibility (LSP4J is good at it as it can have the request return an Either<Command[]|CodeAction[]> for the codeAction request, which is IMO simpler to use than capabilities to decide of how to handle the response).

[mjbvz]

The kind is a big reason we added the CodeAction class.VS Code uses it split code actions by type in order to create different menus for refactoring actions and source action, and I imagine other tools will want to do something similar.

The command and edit actually aren't implemented as exclusive. We apply the command and then the command. I'll update the vscode docs to make this clear.

One other point: we also added an only field to CodeActionContext. This is used to say which types of code actions a code action provider should return.