Page/editor corruption caused by inlined display/include macro that references block content

Repro:

1. Write this source content into Sandbox.InnerFoo.WebHome:

   paragraph 1 inside InnerFoo
       
   paragraph 2 inside InnerFoo

2. Write this source content into Sandbox.OuterFoo.WebHome:

   inline test before {{display reference="Sandbox.InnerFoo.WebHome"/}} and after

3. Observe that the content gets rendered as multiple paragraphs. Even though display was used in an inline context, because InnerFoo contains paragraphs, all of the rendered content gets broken up into individual paragraphs ("de-inlined").
4. Edit Sandbox.OuterFoo.WebHome in CKEditor. Observe that the actual content of InnerFoo "spills out" into the editor. Look at the Source view: the actual contents of InnerFoo have become part of the source content of OuterFoo. You can also just directly Save the page without going to Source view and observe that OuterFoo now contains the literal contents of InnerFoo (in addition to the original display macro). You can repeat the Save repeatedly and each time you'll get another copy of InnerFoo cloned into OuterFoo.
5. Edit Sandbox.OuterFoo.WebHome in the old WYSIWYG editor. Observe that making any edit to the content in the WYSIWYG editor, such as inserting a space anywhere, causes "(((" to get injected into the Source content view of the editor after the display macro's position.

In short there is a major disconnect occurring when block content gets injected into a page in an inline context. This impacts both display and include macros.

The potential user impact is serious, since any page that utilizes one of these kinds of macros runs the risk of inadvertently and silently corrupting the calling page's content every time they save the page from the editor.

The trivial fix is to simply prevent users from injecting block content when in an inline context, by throwing an exception and requiring the user to adjust their XWiki markup accordingly. This is the approach that the html macro currently utilizes.

However, from a user perspective this solution is not ideal. Ideally a user can place a macro anywhere in a page (inline or block context), and XWiki should just do the right thing. In the case of block content being injected into an inline context, it would be best if XWiki could just "de-inline" the context surrounding the block-content injection point. In other words, the rendering behavior as described in step #3 is ideal, but the adverse behavior seen in steps #4/5 should be properly mitigated by XWiki without any specific user intervention.