Introduce an elementToStructure and rangeToStructure downcast helpers with slots for reconversion

[niegowski]

📝 Provide a description of the new feature

This is a follow-up to #9783.

The big picture of the new downcast helpers stays the same as in the above issue. 

In the previous issue we were trying to PoC the solution:

• reconversion was shifted from DowncastDispatcher to DowncastHelpers and a more streamlined approach to bringing back (reuse) old view elements was introduced with the slots that are placeholders that could indicate where the child view elements should land in the final view structure 
• the first reconversion approach with declarative triggerBy was updated to be a facade for the more flexible callbacks
• the first approach to range conversion (for structures like lists that are a flat list of elements in the model but convert to a complex structure in the view) 
• the early prototype of usage of the rangeToStructure that proved to be difficult to describe the triggerBy to detect changes and find a proper range.

The most difficult part was to handle the range reconversion - it was simple for simple cases like adding elements, changing attributes, or promoting some element to become a part of the ranged conversion, but for those cases that act in the opposite direction like removing elements, removing attributes, it was difficult to find proper ranges and apply changes properly. The number of edge cases was growing. For example, who should be responsible for converting a paragraph that once was a part of a list but not is a plain paragraph between two lists? There are some ideas that we want to investigate to solve those issues and provide an understandable API for developers:

• The default remove downcast conversion is based on position mapping, and for complex view structures, it's not always ok that we just map the range and remove everything inside it. There are cases that a single model element is mapped to multiple view elements (this is a case in lists, tables). In those cases, it should not remove only the range that is the best guess but should use the outermost range that still fulfills the mapping.
  • For that, there is an idea to introduce an option for position mapping to find innermost or outermost positions. For remove downcast the outermost range should be used but for selection mapping the innermost.
• Responsibility for converting a split range - like an item in the list promoted to a plain paragraph that splits the list into two lists with the paragraph between them.
  • The idea is to split the reconversion process deeper than a single converter. 
  • The conversion would use the remove (or removeRange) downcast to remove the old view but then the insert (or insertRange) would be responsible to reuse old view elements.
  • This could be handled by keeping the temporary mapping of model-view elements so that they could be reused in any converter in the same conversion process.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.

[Reinmar]

We need a new spike. Closing this one in the previous iteration.