Fixes#4602 as per https://github.com/wagtail/wagtail/issues/4602#issuecomment-479539444 (option 2).
Previously, given HTML input such as:
<p>
<i>a bunch of text before <embed alt="somepic" embedtype="image" format="fullwidth" id="1"/> after</i>
</p>
the `<embed>` would start a new block, but the converter would keep hold of references to currently-open tags such as the `<i>`, so that when the corresponding `</i>` tag was encountered, it could match it up to the opening tag and fill in the 'length' field on the resulting InlineStyleRange object. However, since the span length is calculated based on the text content of the _current_ block (which is now "after"), it would obtain the wrong result - or, when there is no content between the embed and the closing tag (and thus no current block), would throw the exception `'NoneType' object has no attribute 'text'`.
In this new approach, when the embed is encountered, the current block is closed _along with all of its styles and entities_, causing the lengths of those spans to be filled in correctly. After inserting the embed, the current block is then set to a replica of the previous block with all those styles and entities reopened, so that when the closing tag is finally encountered, the span length is correctly set based on the new 'after' block.
This replaces several US English dialectical uses of _regular_ with
British English equivalents _normal_ or _standard_. This is the result
of a search of the docs for the string 'regular', rather than due to any
US English seen in the user interface.
This search also found one use of _regularly_ where _often_ was closer
to the intended meaning, a change which is less about dialect than about
word choice.
The rationale for these was to keep the control flow in one direction, so that the child blocks don't know about the wider sequence they belong to. But that's already undermined by the fact that they have to keep track of their own index number, and it just makes things needlessly unwieldy, particularly when we go on to make action buttons pluggable (and emphatically want to avoid having a mass of abstraction between the button and the action it performs).
Fixes @cnk's test case from #7248. blockErrors within a ListBlockValidationError is an array (with nulls for the items with no errors), but setError was treating it as a dict keyed by block index, which meant it was erroneously passing nulls to the child setError method. FieldBlock handles this gracefully, but other blocks such as StructBlock don't.
Some edit handlers, such as the 'unofficial' PerUserContentPanels recipe from #4749, vary their field list according to the current request/instance by hooking into bind_to. This was not being called on the comparison view, meaning that when these edit handlers are in use, the field list was never getting populated and so the view was wrongly reporting no changes.
Note that the bind_to method also allows binding a form, which we do still skip (since the comparison view doesn't construct one).
Matt Westcott