Implemented Symfony reverse proxy support for user context hash.

> Ref #26
> Relates to https://github.com/ezsystems/ezpublish-kernel/pull/1025

Finally the PR :smile: 
This adds support for Symfony RP for user context hash feature.

For this to work, you need to:
* Make your `AppCache` class extend `FOS\HttpCacheBundle\HttpCache` instead of `Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache`.
* Ensure `USER_HASH_ACCEPT_HEADER`, `USER_HASH_HEADER` and `USER_HASH_METHOD` constants match your configuration (cannot rely on semantic config here as we're way too early for that).
* Ensure `SESSION_NAME_PREFIX` matches your environment.

In any case, it is possible to redefine those constants to fit your configuration.

## TODO
* [x] Implement user context hash support for Symfony RP
* [x] Clear documentation on how to set it up
* [x] Make user context hash response vary on sessionId(s) only as Cookie may contain undesired info (e.g. analytics)
* [x] Try to do some tests
hm, the signature of the HttpCache constructor has $options. why not have this and then keep a copy of $options for us?
```
public function __construct(HttpKernelInterface $kernel, StoreInterface $store, Esi $esi = null, array $options = array())
{
$options = array_merge(array(
            'user_has_header' => 'X-User-Context-Hash',
            'user_hash_uri' => '/_fos_user_context_hash',
            // ...
), $options);
$this->fosOptions = $options;
parent::__construct(...);
```

i see the thing about missing getOption on the HttpCache, otherwise we would not need a $fosOptions property. we can then follow the same logic and have a private $fosOptions method. and, if you want, a getFosOption() method but i think it should be ok to set all options in constructor and not later. they should not be dynamic i guess.