Review all the different Notifications/Channels that we have throughout the interfaces in the notation module

We have many interfaces, and many notifications, and it isn't always immediately clear through which interface an operation should be done, or through which notification/channel we will be notified of which things.

Examples of unclear task distribution over interfaces:

• Shadow note is managed by AbstractNotationPaintView and NotationInteraction, but the rest of note input goes through NotationNoteInput.
• Retrieving the selection goes via NotationSelection, but changing the selection goes through NotationInteraction.
• (not really about interfaces, but) I keep being confused about the task distribution between AbstractNotationPaintView, NotationViewInputController, NotationInteraction

Examples of notification unclarity:

• When exactly is notationChanged fired? When an undo stack transaction (begin/endCommand) is performed? Or also when the view mode changes, for example? Well, apparently also when just a style value is changed in the style dialog, while that's not a complete transaction. But not for some actions that go through the NotationNoteInput interface, and also not when doing actions that don't go through NotationInteraction, but just use NotationUndoStack::prepareChanges/commitChanges.
• It feels not great to have notationChanged and changesChannel. They are very similar, but not the same, but the difference is far from obvious.
• Judging from NotationInteraction::apply, there's sometimes also a dropChanged notification, that's emitted instead of notationChanged, making notationChanged even less general/reliable.
• if you need to do something when the selection is changed, and when the notation is modified, you'd need to subscribe to both notifications, but sometimes both are fired for the same transaction, so your handler will be performed twice. We don't have a general way of handling this.

It seems time to review the interfaces and notifications we have, and increase consistency and reduce redundancy.