Remap refactor get leader key original action and handle plugins through mappings

[berknam]

What this PR does / why we need it:
It creates a new way of handling plugins. Now the plugin's main actions are registered through the new @RegisterPluginAction(pluginName) which takes the new BasePluginAction with the new property pluginActionDefaultKeys: string[] which holds the keys that will be used to create the default remappings. The keys property now needs to have the plugin action name (the same as used by that plugin in Vim) as the first key, but can have more keys.

Examples:
Plugin: CamelCaseMotion
Action: Move "word"
In Vim you would do map <leader>w <Plug>CamelCaseMotion_w, here we have:

@RegisterPluginAction('camelcasemotion')
class MoveCamelCaseWordBegin extends CamelCaseBaseMovement {
  pluginActionDefaultKeys = ['<leader>', 'w'];
  keys = ['<Plug>CamelCaseMotion_w'];

  public async execAction(position: Position, vimState: VimState): Promise<Position> {

Which when registering will create the default remapping <leader>w -> <Plug>CamelCaseMotion_w, here we handle <Plug>CamelCaseMotion_w as a single key.

Plugin: Sneak
Action: find 2 chars
In Vim you would do nmap s <Plug>Sneak_s, here we have:

@RegisterPluginAction('sneak')
class SneakForwardNormalAndVisualMode extends SneakForward {
  keys = ['<Plug>Sneak_s', '<character>', '<character>'];
  pluginActionDefaultKeys = ['s'];
  modes = [Mode.Normal, Mode.Visual, Mode.VisualLine, Mode.VisualBlock];
}

Here even though we have 3 keys for the action we only map the pluginActionDefaultKeys to the first key of keys, so we get a remap of s -> <Plug>Sneak_s which when it gets to the action handler waits for two more keys of type <character>.

This was implemented on all plugins and since I was changing them I also added some features to them (this method actually makes it easier to add more features from these plugins) like the <Plug>Sneak_t, <Plug>Sneak_T from sneak and the keys 'cS', 'yS' (operator), 'ySs', 'ySS' (same as 'ySs') and 'gS' (visual mode) from surround plugin.

On register we create the default mappings but we add them to the mappings Maps when loading config depending on whether the plugin is active or not, we also don't add the plugin default mapping if the user already has a map for that key. Example: if the user has this map: w -> <Plug>CamelCaseMotion_w we don't create the mapping for <leader>w. This is a behavior that a lot of plugins do in Vim as well.

The result of all this is not only do we have a better implementation of plugins, we also get the original action of the <leader> key back. Now if you press the leader key it waits for timeout when it has potential mappings, but after timeout finishes it executes its original action. If you don't want to wait, you can now create a different NonRecursive mapping to the leader key. For example if you set your leader to ,, you can do:

"vim.normalModeKeyBindingsNonRecursive": [
    {
        "before": ["\\"],
        "after": [","]
    }
]

And this way you get the original action of , with the \ key.

The next step with this is to be able to read the mappings from .vimrc that use <Plug>. I intend to do this by storing all the <Plug>name that we implement on the RegisterPluginAction, then the vimrc builder can use those stored implemented plugin actions to regex the vimrc for compatible plugin actions. This would mean that we would be able to read the following remaps from vimrc:

map w <Plug>CamelCaseMotion_w
omap iw <Plug>CamelCaseMotion_iw
nnoremap <leader>s" v<Plug>CamelCaseMotion_iw<Plug>VSurround"

Which issue(s) this PR fixes
fixes VSCodeVim#4916
fixes VSCodeVim#2027
fixes VSCodeVim#4909
fixes VSCodeVim#4973

Special notes for your reviewer:
This PR is based off of the PR VSCodeVim#4735