Add keyboard support for moving and zooming elements and viewport

[aylin-sarioglu]

This PR is part of my diploma research conducted at the Model Engineering lab of TU Wien in the Business Informatics Group. It introduces the move and zoom functionality.

Examples

Move elements

1. Select one or multiple elements
2. Use the arrow keys to move the element(s) accordingly

Move viewport

1. Focus is on viewport , no elements are selected
2. Use the arrow keys to move the viewport accordingly

Zoom elements

1. Select one or multiple elements
2. Use + or - to zoom in/out into the direction of the element or elements
3. Use CTRL + 0 to reset to default zoom level

Zoom viewport

1. Focus is on viewport , no elements are selected
2. Use + or - to zoom in/out in viewport
3. Use CTRL + 0 to reset to default zoom level

@martin-fleck-at, @ndoschek

Part of eclipse-glsp/glsp#1029

[ndoschek]

Hi @aylin-sarioglu, thank you very much for your contribution. I'll look at it at the beginning of next week.
Could you please rebase to latest master in the meantime to resolve the conflicts? Thank you :)

[ndoschek]

Thank you very much for this great contribution @aylin-sarioglu! ✨

In general it looks good to me, I added some comments inline, mainly addressing naming and some minor restructurings.

And there are two subjects I would like to discuss:

• I noticed that the key listeners do not support any sort of "key stroke debounce" atm. As soon as I start zooming/moving very fast (e.g. hitting + very quickly and frequently without a significant pause) the animation (i.e. the execution of move/resize) slows down significantly. Could you please have a quick look if there is some way to debounce the execution of the keyDown event?
• Regarding the key listeners in general: I tested this feature also with the Theia integration and it works great in this context as well. However, it would be awesome, if we could continue the approach of separating the key listener and the actual executor by wrapping the current keyDown behaviour in a separate Action.
  This would have the benefit, that we can then simply re-register via the GLSPDiagramKeybindingContext for the theia-integration. This way, the bindings appear in the keymap too, which allows the user to browse all available shortcuts as well as edit them to their liking (although I agree with you here, the shortcuts for moving and zooming are already the perfect fit 😄).
  
  For example, the MarkerNavigatorKeyListener only triggers an action, which is handled by a separate action handler NavigateToMarkerActionHandler. For the standalone example, the marker navigation is register to the keybindings Ctrl+./Ctrl+,. For the theia-integration it is then registered via a keybinding contribution under the previously mentioned diagram context. The following screenshot shows that keybinding in Theia and that it's linked to the diagram context:
  
  
  As an example you can test the differences between the standalone and the theia-integration if you additionally register the markerNavigatorContextMenuModule for the standalone example. Then you can observe, that the marker navigation works in the standalone via Ctrl+./Ctrl+, and in the theia-integration via F8/Shift+F8. (First you have to validate the model via the checkmark tool in the toolbox, this creates issue marker on some nodes. You can then navgiate between those markers.)

Thanks again Aylin for your great contribution!

PS: I'm sure you already noticed, but the current theia-integration example does not offer the keyboards shortcut overview by default. You can activate this by adding the @theia/keymaps dependency to the example browser-app.

[ndoschek]

Hi @aylin-sarioglu, thanks for the great improvements ✨!

Overall it looks good to me, I added a few minor comments inline.
Once they are resolved, I guess we are close to merging this pr 👍
Please also squash your commits, thanks!

And one thing, as I am looking again at the code, perhaps it would be a good idea to nest the move-zoom and view-key-tools features inside the new accessibility folder now as well-
This would group all the features in the accessibility context in one directory, which would be useful for later maintenance after all.

I'd suggest to go with this structure:

[ndoschek]

Thank you @aylin-sarioglu for the quick updates! ✨
Looks good to me, I just have one minor comment left.
If that's fixed, we are good to go from my POV :)

[ndoschek]

Thank you @aylin-sarioglu for the quick updates and the reporting of the bug! 👍