Draft: Add "pan while painting" capabilities to some tools

This mr add the ability of triggering the pan input action while "painting" (aka while the tool primary action is active).

When some tool is performing some action the canvas input actions (pan, zoom, etc.) are not triggered. This prevents, for example, the ability of activating the pan action while the user is performing the primary action. Usually this is expected, but there are some tools that can benefit from that feature. Mostly the tools that require click and drag over a long distance with precision. For that it is useful to zoom in a bit to gain the precision, but this means that the action cannot cover big distances relative to the image size.

An example is the freehand selection tool: it is common to use it to make a precise selections, but since the canvas cannot be panned, one has to compose the final selection by adding various smaller selections perform, and the process requires a series of select-pan-select-pan-etc actions. Another example is making a line from a specific point to some other specific point: currently one has to zoom to hit those required points precisely and go to the canvas border and rely on the auto scroll.

This mr adds the following changes:

• All the meat of the pan action tracking is in one single class that can be reused very easily. This means that the changes to the specific tools are minimal.
  • I had to add some attachLowLevelPriorityEventFilter and detachLowLevelPriorityEventFilter member functions to KisInputManager since the filters added with attachPriorityEventFilter are not called is a shortcut is already being processed. The problem is that if the user is clicking and dragging the filters are not called.
  • I added a convenience shortcutsForAction(const QString &actionId) member function to KisInputProfile to retrieve all the shortcuts for an specific action id.
• I made use of this new class in some tools that follow that "click+long_drag with precision" paradigm: line tool, gradient tool, rectangle/ellipse shape/selection tools and freehand selection tool. Other tools like polygon work by performing multiple clicks so the normal pan action can be activated between those. Likewise I don't think that the brush tool for example needs this. Even if it is usually used as "click+long_drag", the effects are local: what you are painting currently does not depend on the previous points of the stroke nor will change the previous parts of the stroke, as opposed to moving the end point of the line tool, which changes the whole line, or the last point of the freehand selection tool, which if it is not well positioned can make the final shape self-intersect in weird ways.
• I also changed the way the line in the gradient tool is painted. Before a line was painted directly on the painter, which produced bad results depending on the zoom level (maybe due to the pen not being cosmetic?). Now it uses the paintToolOutline method.

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.