EditorDataContext cannot be used because the platform cannot convert it to the async data context. Taking the fact that it's not clear why this custom context exists, I decided to get rid of it at all.
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
This context was added long ago, but I wasn't able to find specific reasons for that. Currently, such custom contexts cannot work with the intellij platform and should be refactored or removed. The issues with this context are that it cannot be converted to the async data context by the platform.
Taking the fact that the reason for this context was not found, I decided to get rid of it.
The issue from the platform looks like this
```
Cannot convert to AsyncDataContext at 'keyboard shortcut' DataContextWrapper(CaretSpecificDataContext(com.maddyhome.idea.vim.helper.EditorDataContext)). Please use CustomizedDataContext or its inheritors like SimpleDataContext
```
Here the EditorDataContext is mentioned instead of CaretAndEditorData context, however, I'll clean up both contexts during this refactoring
It was used in the action system for mapping to the `<Action>` keyword and in commit 256f5fcd0e it's mentioned that the EditorActionHandler was not working without this context. However, currently both cases work fine without addition wrapping.
Register groups for the caret do not use some fields from the base class, however the listener for these fiels is still registered. Now we don't register this listener.
Generally it looks like a bigger refactoring can be performed in order to separate the common registers logic from caret registers logic.
This change should improve the performance of the IjVimCaret initialization because now we won't register a new disposable on each instance of IjVimCaret
This is a part of VIM-3336
We want to avoid unnecessary OOP and use interfaces only for cases where we will have different implementations for different IDEs
This service will help us in our future refactorings of SearchGroup and SearchHelper
The fact that these methods only return local editors (i.e., editors for the local user while hosting a Code With Me session) is an implementation detail
This means we listen to changes in all documents, rather than just the changes in the documents for open local editors. And this means that we correctly update e.g. marks when a non-local editor changes a file that isn't open in a local editor.
Reviews all IntelliJ listeners to ensure that they only work with supported local editors. Editor creation was initialising IdeaVim for all editors, which meant that behaviour could leak into Code With Me guest editors. E.g. guest editors incorrectly drawing relative line numbers, or the host using the guest's last selected tab when switching to an alternate file.
This leads to a change in behaviour with some local editors. The editor creation listener will now check to see if the editor is local *and supported*. This means it can exclude single line editors, editors in database cells or dialogs, depending on the state of 'ideavimsupport' at creation time. The behaviour at creation time is now more correct, but if 'ideavimsupport' is modified, existing matching editors will not be initialised.
Fixes VIM-3274, fixes VIM-3275
