Refactor and fixes

The actions in 2D mode was refactored to work with multiple clicks instead dragging and dropping. The refactor of 2D actions is really good, as it separates the actions which process the view from actions which work with shapes, and in the future there will actions that will edit the shapes.

Anyway, going to 3D things is more complex: as far as I've looked there are multiple sources that defines an action, and roughly for now they are:
- actions that model the view
(and here are actions that create a real shape: )
- actions that are 2D and work in 3D, so they will work projected in a plane, which plane needs to be changed
- actions that work in 3D directly with 3 or more clicks
- actions that work with a shape, and processing (like extrude)

On second thoughts, the code of 2D actions is not enough, because for now the actions are limited yet to a number of clicks and this is all, and the actions may have clicks or mouse move almost exclusively. One limitation (that will be fixed over in the future) is also that the solver should adapt basing on the selected plane. And for other actions it will not be used.

So the limitations of the 2D actions are the following:
- the action itself should handle a lot of the input code because the events are simple (clicks)
- the custom plane should be fixed outside the action by the user in an invisible way (for now my code is with predefined planes, but the user should be able to select a face, and to edit on it, and it will work)

- the actions should be able to treat multi-actions open-ended clicks (like polylines... where the action knows "when to stop")
- the actions may want to have the solver with different behaviors corresponding with the plane or rules, but only in some actions.

Most of limitations rely on how the input is generated. It can be generated in every possible way: it may be a shape, simply the view that it applies to, a double stating the width of the extrude, etc. Another limitation is that an action can never reply it's status, if you select a line, the line keeps the track of all mouse inputs, and it tries to create things depending on the first or the second point selected.

What is the plan?

The next step is to separate the input code OUT of the actions code. The code will still have some code that asks for a separate input, but it will do something like this: asks for a shape, asks for a double, do the extrude or: asks the first point, the current selected plane, the second point, and based on that, it will do a line. Also, this leads to a possibility to not make hacks to select another plane or to be sure that one is selected. Probably the code will be similar in future with Functions' dependencies code, but this is not such a easy to do task for now.