[HttpKernel][HttpCache][RFC] SSI kernel proxy

Bug fix: no
Feature addition: yes
Backwards compatibility break: possible
Deprecations: possible
Fixes the following tickets: ~
Todo: see below
License of the code: MIT
Documentation PR: ~

Yes this is my second pull request about SSI-implementation (third, if you count the closed pre-`HttpKernel`-refactoring PR), but I came to the conclusion, that it could be more appropiate to separate `HttpCache` and the substitution of the include tags from each other, but before I put to much effort in an unwanted idea, I want to hear some opinions.

The motivation/idea
-----
- Separation of concerns: `HttpCache` can concentrate on its purpose. Therefore I would separate the esi-substitution too. This should make both easier to maintain
- The substitution is useable without the cache, for example as a fallback, or for development, where/when caching is not wanted.

As a sideeffect `HttpCache` (when used) will cache the original content including the ssi-tag and the parsing of the tag will occur on every request. But we can get rid of `eval()` :wink: 

    // with cache
    $kernel = new SsiKernelProxy(new AppCache($kernel);
    // without cache (just subsitute)
    $kernel = new SsiKernelProxy($kernel);

The first commit contains the SSI rendering strategy, which is exactly the same as in my other PR.

The second commit is the single class `SsiKernelProxy`. When ESI should be separated too I would rewrite it into a `IncludeKernelProxy`-class, which consumes one or more `IncludeSubstitutionStrategy`-objects, that handles the differences.

    // example 
    $kernel = new SsiKernelProxy(new AppCache($kernel,
        array(new SsiSubstitutionStrategy,new EsiSubstitutionStrategy)
    );

TODO
----
- For now the proxy doesn't respect any `Surrogate-*`-header, but I probably should
- When from a server a `Surrogate-Capability` with the corresponding value (I guess `SSI/1.0`?) is set, this proxy should passthrou the request without handling, so it act as a fallback
- I would like to handle `maxage` and `s-maxage` separately: 

        $maxage = min($maxages);
        $sMaxage  = $shared ? min($sMaxAge) : 0;

    In the current esi-implementation `maxage` is always set to `0`, but when I get it right it is more probably, that a on this way constructed page is private, than that it is public.


The current implementation already works in my demo-application.