Refactor Code Actions

[lukel97]

Code actions and plugins

At the moment, we have one big module CodeActions.hs that does all the logic for taking in diagnostics and spitting out code actions. Ideally, all of this logic should be done inside the plugins so that CodeActions.hs can gather them up without having to deal the specifics of each plugin.
As a rough idea, the PluginDescriptor could take on another field to help produce code actions:

data PluginDescriptor =
  PluginDescriptor { pluginName :: T.Text
                   , pluginDesc :: T.Text
                   , pluginCommands :: [PluginCommand]
                   , pluginCodeActions :: [Diagnostic] -> IdeM [CodeAction]
                   }

Command identifiers

Currently command identifiers are passed around as strings, and have a lot of dodgy logic for converting to and from their unique, PID prepended counterparts. This should be refactored so that they are strongly typed, and the PID-ifying is done behind the scenes.

Todo

• Add new field to PluginDescriptor
• Migrate existing plugins over
• Refactor command identifiers

[alanz]

@bubba I just noticed that the docs for a CodeAction say

If a code action provides an edit and a command, first the edit is executed and then the command.

The current wrapCodeAction behaviour ignores the command if there is an edit, when there is no literalSupport.

I am not sure what the best way is to group this so that if the user in the client chooses the action, both things happen, in the required order. Perhaps we should receive a specific wrapper command, that returns the workspaceEdit and then executes the command.

[lukel97]

@alanz yeah we should probably just bundle up both the workspace edit and command, into the fallback command, good eye