This task proposes some improvements on the Stunner client side methods and commands related to "docking" in order to reduce the amount of code and improve its readability, comprehension and the testing effort.

The goal is to split into in parts the resulting operations a node is being docked, also decoupling this way the operations to be performed into multiple commands.

Usually when the users interacts with the UI / canvas, the target location for docking is being given by the mouse event location itself, but there are other implications for:

• Preview panel - Because on the preview context, there is no user interaction, no mouse event, due to the preview is being addressed via command replication
• Dragging nodes from the palette - It does not depends on the location where the user drags, it just obtains some "empty" location to place the node after being docked. This way once dragging multiple elements into a node which allows the docking, it will automatically place the nodes being docked side by side at some "empty" place

Due to the above implications on the preview and palette, actually there exist two canvas commands in order to dock a node:

• Dock node command - See factory method
• Dock node and update location command - See factory method

The goals for this task are:

• Refactor the canvas command factories and the canvas commands related to docking in order to avoid the possible location update after docking is being performed
• Instead, should be top level Stunner commands or components which should composite the DockNodeCommand and an additional UpdateEleentLocationCommand , where the location can be obtained even from the mouse event, in case the user is interacting with the canvas, or automatically by performing whatever calculations on the shapes and their states and locations.
• Also refactor the AbstractElementBuilderControl and sub-types affected - Docking and containment are not allowed for all graph element kinds, just is allowed between nodes. So does not makes sense that the abstraction for the BuidlerControl, which can be used for nodes or edges, contains code related to docking / containment (eg: here, here)

PS: This task has been identified during the work on https://github.com/kiegroup/kie-wb-common/pull/2345/