Support for editing drawn shapes afterwards

Nobody has claimed this yet.

Seems like every drawing app should have this, so you can arrange stuff on the canvas. The main way to do that is to implement support for layers, although you could also do what Google drawing does and basically make every shape its own layers.

-----

*Edit from @maoschanz to get a checklist visible from the issues list*

The history manager should get new methods:

- [ ] `start_last_op_correction()`
- [ ] it switches to the related tool
- [ ] maybe puts a blue "`selection-mode`" css on the headerbar (the corresponding method will not be implemented by all `DrDecoManager`s)?
- [ ] maybe it locks any attempt to add operations to history?
- [ ] at least it disables undo/redo
- [ ] it tells `DrImage` to redirect the mouse inputs to a special method of the active tool
- [ ] it draws handles on the path's vertex, if any
- [ ] the handles can be moved using the mouse
- [ ] `apply_last_op_correction()`
- [ ] restores the editor in its normal state
- [ ] rebuilds the image using the corrected values for the operation
- [ ] `cancel_last_op_correction()`
- [ ] restores the editor in its normal state
- [ ] rebuilds the image using the preexisting values for the operation

In the UI:

- [ ] the button has `error-correct-symbolic` as its icon
- [ ] when the correction mode is active, its button changes to whatever icon i use as "apply"
- [ ] maybe the entire history box should be replaced, to get a button "cancel" too
- [ ] switching tabs, or closing a tab, or switching tool, or whatever attempt to break the workflow, will call `cancel_last_op_correction()`

At this point, only the last one is editable. To make any operation editable, which is a debatable idea in terms of UX, the following modifications should be done:

- [ ] the button opens a dialog with a list of all operations. It smells like shit because i don't have any labels to put in such an UI. The states might not be pertinent to edit, but i like the idea of at least an editable initial state
- [ ] clicking on an operation undoes until the targeted operation, so it can be edited, and then the following operations are redone. This looks like bad UX?
- [ ] the content of the edited op has to be loaded by the options manager (e.g. setting the width of the line to correct as the content of the spinbutton entry)

I probably forgot some edge cases regarding the abstract selection's numerous possible operations.

Start by locating the history manager, DrImage, DrDecoManager implementations, and the active tool or options manager mentioned in the checklist. Trace how operations, mouse input, undo/redo, and tool switching currently interact before defining the correction workflow. Done requires an agreed scope, implemented correction behavior, and coverage for the listed cancellation and editing cases.

Written by the indexing model from the issue text.