Make sure we warn in cases when conversion events were stopped

[niegowski]

This change is necessary after #10376 when we changed the flow of events. Now, stopping a conversion event may lead to children/attributes of that node not being converted.

Old notes from @niegowski

First, we thought about blocking stopping events, but then, after numerous discussions around this we realized it's not the right direction. Check the first comment under this ticket.

In order to be able to properly fall back to child nodes conversion, we must ensure that the event is not stopped before the handler at lowest priority is called. In the conversion process, we are using the consumables concept that allows more granular handling of what is still there to be processed. In the API docs, we are strictly saying, that those events should be stopped, but there was a change in the code that removed that to allow converters that work as side effect triggers.

Since we are mentioning this outdated behavior in the API docs I would suggest making events fired by DowncastDispatcher and UpcastDispatcher not stoppable to avoid confusion.

This would be a good improvement for #10376 to make sure that the conversion will still work after the changes.

[Reinmar]

Change of plans. Blocking stopping the events is not feasible because we stop them in at least one case (table converters). Instead, try resolving the old #3818.

Notes from the arch guild meeting

• Maybe we could resolve the old issue where we wanted to warn if you didn't consume some model change (didn't convert it)?
  • This would catch the above-discussed situation on a bit later stage. Still, we can document what might've happened (three options: forgot to write a converter, stopped the event, incorrect converter that forgot to consume).
  • We can't assume that attributes are consumed and converted. Upload status, GHS, etc. prove that. Attributes may affect only the data.
  • But structure changes are crucial.
  • This: There should be error when there is no converter to the model element #3818 💀
  • Are there any technical challenges here?
  • Can we make the warning useful (do we have all information there)?
  • Can we quickly prototype it?
    • Should be doable inside the Dispatcher
    • Let's check how many warnings (in automated tests and all-features manual sample) we'll get
  • Update (14.09): It worked fine in the PoC
    • Some things were not consumed, but nothing critical.
    • Compat will continue this.

Refinement

• Scope:
  • Check for non-consumed items (elements, text proxies) and throw an error
    • Where?
      • convertChanges(): YES
      • convert(): YES
      • convertSelection(): NO (not affected by Change the order/flow of events fired by the DowncastDispatcher #10376)
      • markers: NO (markers may not have a visual rep, also not affected by Change the order/flow of events fired by the DowncastDispatcher #10376)
  • Documentation for that error that covers the 3 cases listed in the details:
    • https://www.notion.so/5ddfa79d3ea2408ba8a970db5b2c2936#c11fa6e17f6249feb830d9c275a93179
    • Quickly explain how to resolve each issue
    • Mention in which version of CKE5 this changed
    • Link to this issue?
  • Add missing consumes and fix broken tests