463010: Remember tool opacity after brush switch

This proposed change is an attempt to fix BUG: 463010.

Currently, the opacity is saved only in the active brush. When switching between brushes in the Freehand Brush Tool, the previous opacity of tools that do not use brushes (e.g. gradient, fill) is forgotten. This change updates the tool opacity implementation to override the preset opacity when the tool does not use brushes. The preexisting feature of saving each brush's opacity individually is retained.

To do this, an additional property, KoCanvasResource::GlobalOpacity, is added to keep track of opacity when the brush presets are not active. When the active tool uses the brush presets, the opacity resource converter (renamed KisOpacityToPresetOpacityConverter) behaves the same way it does in existing implementation, so KoCanvasResource::Opacity is linked to the preset opacity. When the active tool does not use the brush presets, the converter is replaced with KisOpacityToGlobalOpacityConverter, which links KoCanvasResource::Opacity to KoCanvasResource::GlobalOpacity. The converter update happens when switching tools, through a signal emitted in KoToolManager. The opacity value for each tool is also stored in the tool, using m_opacity in kis_tool_paint.

Currently, the tools that use preset opacity are the Freehand Brush, Line, Rectangle, Ellipse, Polygon, Polyline, Bezier Curve, Freehand Path, Multibrush, and Dynamic Brush tools. The preset opacity is consistent between all of these tools, meaning that after switching from one tool to another and changing the opacity, the old tool's opacity is lost.

There are some existing limitations with this feature that might need to become future patches or TODOs:

1. As stated above, the tools that use brush opacity must all share opacity per brush. This seems more intuitive to me, as switching between different tools on the same brush tends to require the same settings, and this way is also more consistent with how the brush size works. However, it does limit the artists' choices if they do want to switch the brush opacity between two different tools.
2. The tool opacity is currently saved individually on each document. This is inconsistent with the brush preset behavior, where brush settings stay the same when changing windows.
3. The eraser mode switch opacity setting is still tied to the brush preset. The tool opacity will be saved when switching back and forth with eraser mode, but the opacity behavior in eraser mode is dependent on the active brush. Because this setting is toggled on the Brush Editor, I left it as is.

Test Plan

1. With the Freehand Brush Tool active, select a brush (B1) and set its opacity to an arbitrary value (V1).
2. Select a second brush (B2) and check that the opacity is 100%. Set its opacity to a different value (V2).
3. Switch to another tool that has opacity property (e.g. Gradient Tool) and check that its opacity is 100%. Set its opacity to a third value (V3).
4. Without changing tools, switch brushes back to B1. Check that opacity is still V3.
5. Switch to Freehand Brush Tool. Opacity should be V1.
6. Switch between different brush and tool combinations to check that all the opacity values are consistently saved.

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.
• Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.