Block-only rendering macros are not treated as blocks when the wiki syntax is parsed

Imagine you have a rendering macro that simply outputs this wiki syntax

(% class="foo" %)(((
bar
)))

The macro specifies that it doesn't support in-line mode. It always generates block level content. From the end user point of view the following:

before {{test/}} after

should behave exactly as:

before (% class="foo" %)(((
bar
))) after

but it's not the case. The first leads to an error message:

The [test] macro is a standalone macro and it cannot be used inline

while the second generates, as expected, this HTML:

<p>before </p>
<div class="foo">
  <p>bar</p>
</div>
<p>after</p>

This makes the users ask themselves: if we can "split" the paragraph in order to accommodate the DIV then why can't we do the same with the macro call?

Sure, there is a difference. When parsing the wiki syntax we know that the group syntax is always a block so we close the previous (paragraph) block (and we start a new block). We can't (always) do this when encountering a macro call because:

• the corresponding macro (component) might not exist, so we might not have any information about it (and the macro content is a black box)
• the macro output is not always block, it can be in-line also, if supportsInlineMode is true

Still, if the macro exists and has supportsInlineMode false then it would be much better for the end user to handle it as a block at parsing time, exactly as if it was a group syntax.

The only issue I can think of is if we cache the XDOM obtained by parsing the wiki syntax and then we modify the rendering macro by setting supportsInlineMode true. The rendering won't match the input syntax but I think this is acceptable. We could also make sure to invalidate the XDOM cache when a macro is updated.