It has long been possible to render recursive templates with Fluid,
either by using partials or sections. In both cases, `<f:render />`
is used to initiate the recursive behavior.

For example, the following template creates a recursive main menu by
using sections:

```xml
<f:render section="menu" arguments="{items: mainMenu}" />

<f:section name="menu">
    <ul>
        <f:for each="{items}" as="item">
            <li>
                {item.title}
                <f:if condition="{item.children}">
                    <f:render section="menu" arguments="{items: item.children}" />
                </f:if>
            </li>
        </f:for>
    </ul>
</f:section>
```

However, this was only working because `ForViewHelper` was
implemented as static ViewHelper by using Fluid's trait
`CompileWithRenderStatic`. The trait changed Fluid's handling
of ViewHelpers in a way that variables stay consistent even
during recursions. This was made possible back in Fluid 1.0.5
with 819ca24.

However, this never worked properly with ViewHelpers not using
`renderStatic()` but rather the default `render()` method. In those
implementations, `$this->renderChildren()` is used to access and
render the ViewHelper's child nodes rather than executing the closure
directly passed to `renderStatic()`.

To support recursions also for ViewHelpers not using `renderStatic()`,
this patch introduces new state to `AbstractViewHelper` to keep
track of rendering contexts during recursions. Note that this state
is only used for uncached templates, for cached templates this already
worked without any changes.

To explain the new behavior, let's take the example above and let's
also assume that `ForViewHelper` is implemented using `render()` rather
than `renderStatic()`. In uncached templates, the new behavior works
as follows:

1. `$view->render()` gets called for the template
2. `TemplateParser` creates nodes from template string, among them
one `ViewHelperNode` for each ViewHelper.
3. `RenderViewHelper` gets called by executing `$viewHelperNode->execute()`,
which in turn calls `ViewHelperInvoker`, which in the end calls the render
method of the ViewHelper (in this case `RenderViewHelper::renderStatic()`)
4. `RenderViewHelper` calls `$view->renderSection()`, which clones the
current rendering context and puts the appropriate variables in it. The old
rendering context gets saved to be restored later for the parent template.
5. Inside the section, `ForViewHelper` gets called, we end up in
`ForViewHelper::render()` (because we use our custom implementation without
`renderStatic()`)
6. `$this->renderChildren()` is called for each `{item}`.
7. If `{item.children}` is defined, things get interesting. `RenderViewHelper`
calls `$view->renderSection()` again, which creates and saves another new
rendering context, see 4. We're in a recursion now.
8. With each recursion level finishing, the view restores the original
rendering context, so that the variables before the recursion are available
to the rest of the template file.

So the template/partial/section gets restored properly, but the
`ForViewHelper` still has the last rendering context from within the recursion
because Fluid didn't restore it to the previous state. In fact, Fluid couldn't
really do that from outside because `$forViewHelper->renderChildren()` initiated
the whole recursion and is still running (once for each recursion level).

To solve this dilemma, this patch implements a rendering context stack similarly
to the one used in the `$view` object, but on the ViewHelper level. Each ViewHelper
keeps track of recursive rendering contexts for itself – again, only for
uncached, non-static ViewHelpers.

In addition to that, the patch simplifies the logic of `buildRenderChildrenClosure()`,
which covers both cached/uncached and the contentArgumentName feature.