CURA-12660
This required a refactoring of the management of the active view. The previous behavior was that anyone could set the active view, depending on certain conditions. But now we also have a view that is set by a tool, so sometimes the actually set view would be incorrect. Now each Stage requests an active view, and each tool CAN also request an active view. Then the Controller decides which view should actually be active depending on the active stage and tool.
CURA-12660
The previous method actually doesn't work when Cura is packaged because the plugins paths change. This method is much safer, and uses the actual SolidView instance.
CURA-12660
When a message box is displayed, some offscreen rendering passes (face selection) render an unpredictable result and we are unable to start painting.
This went through a refactoring of the rendering passes. Since doing the offscreen rendering outside the Qt rendering loop caused some troubles, we now use the rendering passes only inside the Qt rendering loop, so that they work properly. Tools also have the ability to indicate which extra passes they require, so that we don't run all the passes when they are not required.
Since this issue also concerns the support blockers placement and rotation by face selection, they have been updated so that they now also always work.
The face selection mechanism using the Selection class was partially working and used only by the rotation, so now it has been deprecated in favor of the new mechanism.
This shouldn't happen on a well UV-mapped, manifold mesh -- well, unless someone manages to click exactly on one of the triangle corners. Better to get this fixed now then to run into floating point shenanigans later.
part of CURA-12543
Refactoring that part to up top caused the problem I think -- getSelectedObject(0) over getAllSelectedObjects()[0] is clearly the better call in this case anyway.
part of CURA-12543
