Introduce new Undo/Redo system

[MrStevns]

This PR introduces a new backup system, aka. the undo/redo system that I've tried to introduce a bunch of times over a few years but never completed or completed but was too big to actually review properly 🙃
What's different about this PR is that everything but backups for strokes and polyline has been scrapped.

Won't that leave us with a less feature complete undo/redo system then, you ask? No, because the old system still exist, basically we can switch between the old and the new system, while we continue to develop it.

Some benefits of that is:

1. Ability to review this PR without having all the bells and whistles.
2. While the PR is small enough, we can tweak and agree on the foundation, which is the main focus of this PR.

In addition to that, in order to avoid leaking the complexity of having two backup systems, all the backup system logic exist in the same place. As such everything including the old system reside now in backupmanager.cpp/h files. The old backup system will work as is and still call editor, which now just redirect it to backup manager but otherwise it's the same.

For simplicity sake and to avoid all kinds of weird edge cases, once the new undo manager has been activated, you'll need to restart the application, same goes for when you deactivate it.

There's still a bit of work before the PR is ready to be reviewed, mainly getting selection modifications working again and some cleanup.

[MrStevns]

I've spend some hours on addressing the latest comments and making the new undo/redo implementation more robust.

• I've changed the terminology from BackupElement to UndoRedoCommand.
• The saveState handling has been improved such that old state can't linger and you can't call the new backup method when the prerequisite data is nullptr.
• I've fixed a memory leak caused by the clone in saveStates
• I've removed the undo/redo prefix, now it's only there for the old system.

Let me know what you think.

[J5lx]

What bothers me is that this abstraction creates a disconnect from how users interact with the program. When I use the pencil, I expect that to show up in the undo history as a use of the pencil. When I use the eraser, I expect that to show up as a use of the eraser. When I use the smudge tool, I expect that to show up as a use of the smudge tool. Yet as it is now, they all show up simply as “strokes”, despite serving fundamentally different purposes. What I’m missing is an individual description for each undoable action as seen from a user perspective, like the legacy system.

You said that you want to ensure that the description is related to the UndoRedoType. However, your implementation goes far beyond that, since it forces the description to strictly match the UndoRedoType. At the same time, it’s not entirely clear to me what the UndoRedoType represents. Internally, the program distinguishes between vector, bitmap, and transform commands. Externally, undoable actions include pencil, eraser, select, move, pen, polyline, bucket, brush, smudge. And then UndoRedoType has a subset of that which is stroke, polyline and selection, and even operations like floodfill are considered strokes when determining their description. It just seems somewhat arbitrary. With that said though, my main concern is the highlighted part above.