Ajax rendering lifecycle for components half broken + Solution.

The current state of affairs for component rendering is, that we render the
components in the ajax case by openening the tag before handling the
control of the rendering to the component. Now this causes several problems.
First component authors are enforced into an artifical update part, which
prevents them from fully utilizing the control possibilities of the ajax API!
Secondly this causes problems in ajax cases where the component does not follow
the structure of one root element having the client id of the component as id.
Third this has caused problems in the past regarding javascript evaluation since
there was no clear way wether embedded scripts needed to be evaled or not (we
settled down on evaling them over both implementations)

Now here is a proposed change to remove that problem:
a) Define a marker interface AjaxAware or PPR Aware
b) The marker interface has to implement a method renderPPR
c) The rendering lifecycle now is extended to following first render the
component as done normally (the ppr aware components can react and render
placeholders), but the components which are render aware then need to be pushed
onto a stack which after the update phase is processed.
Once update is done the all components on the stack need to have renderPPR
called. Where they now have full control over the response xml.
Additionally if an open command from the response triggers a pprAware component
on as child of the original ppr control, the child must be pushed onto a stack.
Once the pprAware processing is done on the parent, the child stack has to be
processed etc...
Until all components are processed.

Advantages of this approach: It would allow full control of the ppr stack for
the component authors while being downward compatible to the existing approach.
Disadvantage you do not have full control over the entire rendering process if
you stack ppr aware components this might cause sidebehavior between ppr and non
ppr aware components if the ppr aware components are badly designed (a tradeoff
which I personally think can be lived with, since the burden is here on the
component author who gains significantly more control over the rendering
behavior of his components)
#### Environment
Operating System: All
Platform: Macintosh
#### Affected Versions
[2.1]

Start by tracing the Ajax component rendering lifecycle, especially how the current handling works. Compare it with the proposed AjaxAware/PPR Aware marker, renderPPR method, and nested component stack processing. Done means the lifecycle gives PPR-aware components full response XML control while preserving compatibility with the existing approach.

Written by the indexing model from the issue text.