The clipboardInput event should always be stopped so we always call stopPropagation

[Reinmar]

📝 Provide a description of the improvement

In #2837 it seems that we only covered the  case when an image is being dropped into the editor. We added this code:

https://github.com/ckeditor/ckeditor5-clipboard/blob/4141ef641dd96defbce5c542401a16c2bebecd8f/src/clipboardobserver.js#L56-L61

And it works since imageuploadediting.js do call evt.stop() when there are files in the clipboard.

However, on normal paste, we don't stop the event. Stopping it in clipboard.js (and changing the priority of that listener from low to lowest cause low doesn't make sense if we always stop it) seems reasonable.

At the same time, why don't we stop propagation of all mouse events, keyboard events, and so on? Why do we talk only about the clipboard? Theoretically we could stop all of the events in all cases cause if something happened in the editor it should be handled in the editor. But then... we don't have observers for all kind of events – we listen only to events that we need to. And that would mean that depending on a feature set, the editor would block some events or not. 

Ideally, taken all that, the editor should not stop the propagation of any event. It's the job of the listener to verify where the event occurred and react or not. However, I know that this is controversial and probably not a way to go too.

So, it seems that the only way around this is to hear the feedback and stop propagation of the events which cause issues to integrators. So far we were notified about clipboard events only by more than one party,  so that makes sense.

[niegowski]

We can't stopPropagation of all drop events because there are cases when that events should propagate - #2837. We should only stopPropagation of handled events.