enh: arrow keys navigation improvements

[SystemChanger]

Requirements: #1264 (range selection on component. Full PR, not the merged part)

1. There is no longer exists an easy way to modify the component figure by pressing keys, which was pretty confusing and unexpected (text insertion to component area).
2. Improved navigation through the components (images, videos, etc.).
   It is now possible to navigate through and edit (with other my PR's) content using only the keyboard (honestly, almost, if we are talking about not using the mouse at all, but it is a good step).
   When component is selected:
   ←, ↑: select end of the previous node
   →, ↓: select start of the next node
3. Improved navigation in tables - now you can use ↑ and ↓ arrow keys to navigate up and down through cells (only on the edges, so you can freely position through the content of the cell as earlier).

A custom handler for arrow keys mainly solves the problem with jumping over components when the selection is on the component positioned before/after them (depending on the offset direction).
The next step may be to further improve the navigation for ↑ and ↓ keys, that will allow navigating between "inline" blocks sections (same as I've done for table rows), e.g. for components (images, video) positioned on a single "line". Right now, I don't know how to implement the fully unified solution to determine the layout, and it also sounds like a crazy idea to replicate the default browser content layout system. For components, for instance, we can use their __se__ classes to define the layout, but it is not universal.
@JiHong88 maybe you know a better solution? Maybe some css adjustments to components classes or other html layout that will lead to intuitive default arrow keys behavior and prevent components elements skipping. If so, just the component selection code in onKeyUp_wysiwygmay be sufficient (but, yeah, it won't be so responsive for key holding, which, on the other hand, may not be so crucial).

Also, we have to note that audio components are "skipped/jumped over" on default arrow key carriage move from text node, so we will need some workaround here, maybe we should add some tricky hidden child to audio figure element to provoke focus on it. <---- Add this to issues after (if) the PR acceptance.

[melloware]

PR has conflicts.