Improve selection tools' use of modifiers

NOTE: This MR is in conflict with !1306 (merged) so review one and once that is merged I'll change the other.

Well, I'm working on an "enclose and fill" tool that uses some different "subtools" to make the enclosing region. For that I need to reuse the functionality present in the freehand selection tool. So I'll have to refactor that.
But first I wanted to tackle an issue with the modifiers that is present in the freehand selection tool: the use of modifiers to change the selection mode can be in conflict with the use of modifiers that the specific tool does. In the case of the freehand selection, the ctrl key both activates the replace selection mode (general to the selection tools) and the continued mode (straight line, specific to the freehand selection tool). This issue was reported at least in BUG:426523, BUG:420737, BUG:420298, BUG:435848.
I asked for feedback at KA (link) and decided to go with @kamathraghavendra's suggestion, so I'm pinging him here.

So, this MR is an attempt to solve and simplify how those issues can be handled. This is what I made:

• I saw that, to some extent, KisToolSelectBase (the class that handles generic selection related stuff) communicates with the specific selection tools' code with the listenToModifiers / listeningToModifiers pair of functions as well as relying in the base class having some hasUserInteractionRunning method.
  This gets intricate because some selection tools interaction code ends as base class of the KisToolSelectBase (rectangle, ellipse, etc.) but in others KisToolSelectBase is the base class (outline, contiguous, etc.).
  So what I did is to get rid of that listeningToModifiers code as well as having the hasUserInteractionRunning in the sub classes, and created a basic interaction notification system in KisToolBase that uses signals, so that interactions can be started/finished at any place in the tool code while every other part (parent class, child, or whatever) can be aware of whats happening.
  Specifically I used this system so that the specific selection code can begin a "select" interaction. Then the generic code sees if the tool is selecting and can prevent the use of the modifiers for changing the selection mode. As well, the generic code starts a "move_selection" interaction when moving the selection, so other code can be aware of that.

• To solve the issues/bugs of conflicting modifiers, I changed the rules a bit, and made them less ambiguous:

  • The selection mode can only be changed through modifiers if the user is not selecting or moving the selection.
  • When the user is selecting, the modifiers can be used by the specific tool as it wants, without worrying about the selection mode being changed.
  • When the user makes a selection, the selection mode used is the one chosen when the user started selecting.
  • When the user finishes selecting the selection mode changes to reflect the currently pressed modifiers.
  • The cursor should reflect at any time the action that is possible at that position with the modifiers pressed (if any). For example if the user finishes selecting, and the cursor is over the selection contour, it should change to the move selection cursor.

• I had to change how the KisToolRectangleBase handles the modifiers to avoid starting the selection in one of the transform modes.

• I added (provisional?) cursors for symmetric difference and intersection. That way there is feedback when those modes are selected.

Test Plan

• Use all the selection tools with different modifiers.
• Use the selection tools that use modifiers for custom behavior (like freehand selection tool).

Formalities Checklist

• I confirmed this builds.
• I confirmed Krita ran and the relevant functions work.
• I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
• I made sure my commits build individually and have good descriptions as per KDE guidelines.
• I made sure my code conforms to the standards set in the HACKING file.
• I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.