Fix EZP-23513: embed rendering (XmlText)

This PR resolves https://jira.ez.no/browse/EZP-23513

Part 1 of 2, second PR will handle RichText field type.
Part 2 of 2 handling RichText is available here: https://github.com/ezsystems/ezpublish-kernel/pull/1091

Reported issue is about paragraph being rendered around embedded Content. However, fixing this revealed a number of other problems with embed rendering.

**First** one is _expansion_ of paragraphs containing block level embeds. In legacy `ezxml` this is allowed, and XML like this one:

```xml
<paragraph>
    Some text
    <embed/>
    Other text
</paragraph>
```

will be rendered like:

```xml
<paragraph>Some text</paragraph>
<embed/>
<paragraph>Other text</paragraph>
```

**Second** one is about linked embeds. In legacy `ezxml` embed is not a link by itself. This is done through wrapping the embed element inside a link. Aside from embed element, link can also contain other content. This is best explained by example, XML like this one:

```xml
<paragraph>
    Some <link>linked <embed/>text</link> and something else
</paragraph>
```

will be rendered like:

```xml
<paragraph>
    Some <link>linked</link>
</paragraph>
<link>
    <embed/>
</link>
<paragraph>
    <link>text</link>and something else
</paragraph>
```

Other inline elements can enter the picture here, and all are correctly handled by Legacy Stack, but this kind of _expansion_ was not handled by new stack at all.

That is the cause of originally reported issue.

**Third** problem is that link that wrapping the embed is actually interpreted as a property of embed itself, although it is represented by a separate element. Legacy Stack handles this by passing `link_parameters` to the embed template. This was also not handled by new stack, not XmlText nor RichText (which implements conversion to and from legacy `ezxml` format). In RichText this use case was not recognized, and will be fixed in the following PR together with `ezxml` conversion.

**Fourth** problem is usage of temporary paragraphs to wrap block level elements. These are the paragraphs defining local `tmp` namespace. Such namespace definition is inherited by all descendant elements, which really means that in case of nesting, they are unusable in XPath (and therefore in XSL transformation). This was therefore handled imperfectly in XSL transformation. Partial fix for this problem was implemented in `CustomTags` converter, which uses PHP's DOM API to recognise local `tmp` namespace definition on a paragraph, through checking for it as an attribute. `CustomTags` pre-converter is here removed as new `Expanding` pre-converter took over its function.

Described problems are here fixed as follows:

1. Paragraph expansion is handled by new `Expanding` pre-converter.
2. Linked embeds inside a paragraph are handled by new `Expanding` pre-converter, which will keep the link around the embed element while expanding the paragraph into multiple paragraphs and extracting the embed element out of it.
3. Interpreting embed's link as a property of the embed itself is handled first by new `EmbedLinking` pre-converter, which will add link properties to the embed, and also unwrap it from the link if required. After this the problem is handled by `Link` and `Embed` pre-converters. First one will resolve the link that is added to the embed element, and second one will extract link data and pass it to the rendering process. The template will receive this data in form of `linkParameters` variable, which will be converted to the Legacy Stack format in the case of fallback.
4. Handling temporary paragraphs is done in `Expanding` pre-converter, which will through PHP's DOM API check for the local namespace as an attribute and add an attribute so that it can be sanely handled in XSL transformation. This also led to some simplification of the XSL transformation.

Inline level embeds receive the same treatment like block level embeds, aside that they are not unwrapped from the link if the link contains other content as well. In this case (new stack only) `linkParameters` contain `wrapping` boolean parameter, which signifies wrapping status and enables correct handling of the context.

With this changes embedding logic introduced in #1059 was also simplified as announced.

`linkParameters` variable passed to the template looks like this:

```
'linkParameters' => array(
    'href' => 'http://ez.no',
    'target' => 'target',
    'title' => 'title',
    'id' => 'id',
    'class' => 'class',
    'resourceType' => 'LOCATION',
    'resourceId' => '111',
    'wrapped' => false,
)
```

This structure is intended to be kept for RichText as well, so it is here to stay.
Therefore you might want to give it special attention in review.

Testing: unit tests and manual integration tests.
Is that variable really needed? Looks like useless temp variable to me.