Close up shapes in Knife Tool and other small changes

• Remove code responsible for removing all shapes in case where the user just clicked or something similar; no idea why it was there, it should instead just leave everything alone
• close and merge shapes when converting from QPainterPath to KoPath (outside of KoPath, we could only close the last shape; now all of the shapes will be closed, which is way better)
• move initialization parts to static functions to make the code a bit cleaner and allow creating unit tests for those pieces of code
• avoid creating a command in Knife Tool until it seems to be necessary, to not create a superfluous undo entry
• improve coding style
• avoid a crash that should only happen in unit tests (but still, better to avoid than not)
• improve performance by moving code that goes through a for function into a conditional scope
• remove an unnecessary performance check (it was basically doing the same as another check, and therefore only slowing everything down instead of making it faster)
• improve coding style again by streamlining the logic inside one of the functions
• add unit tests

As usual, the best description of the code is inside the commit message for each of the commits. They all are pretty minor changes and improvements to the Knife Tool code. The only potentially different part is the KoPath code.

Test Plan

Run the unit tests. Check whether the Knife Tool still works. Check whether any other code that uses the QPainterPath -> KoPath conversion also still works.

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.