undo/redo extension

[Trinitou]

already discussed in #161 and #223

Now I found time to do a first draft. I tried to (hopefully) integrate suggestions the came from different people in those threads.

Some questions I already have:

• Should
  • perform_undo and perform_redo return bools and not call mark_dirty_for_undo/notify_undo afterwards
  • perform_undo and perform_redo return nothing and call mark_dirty_for_undo/notify_undo afterwards (maybe simpler but more redundant?)
• Is there a better, shorter name than 'incremental change event object' (to all native speakers out there ;) )?
• Maybe @baconpaul: In this current draft, I assume that 'incremental change event object's can be applied in both directions (for undo AND redo). Or should there rather be two types: 'incremental undo objects' and 'incremental redo objects'?

[abique]

Maybe the change related to the stream notes could go in a separate PR?

[baconpaul]

left some thoughts

[Trinitou]

Another aspect might still be missing: The host can only apply the undo/redo objects one by one via apply_event_object ATM. But what if it want's to perform multiple undo/redo actions in a row (e.g. when clicking a node in an undo history or pressing undo/redo key command really quick). Even worse, if those undo/redo steps contain a lot of preset changes, the plugin jumps between different presets.

Therefore, the plugin would want to first get all objects at once and then can decide to skip some updates (if there is a complete state change in a later object)

[Trinitou]

Added a begin and end method as an approach for the issue described in my comment above.