EZP-30662: Add proof of concept cache scenario

[mnocon]

JIRA: https://jira.ez.no/browse/EZP-30662

This PR:

• adds basic cache scenarios
• adds Chromium driver (parallel to Selenium) to our Behat setup. Selenium doesn't support response header checking: http://mink.behat.org/en/latest/guides/drivers.html
• adds support for Content Editing ❗️

As http-cache is disabled I can't say the app is working correctly, but the test will do its job when time comes ;) This is a proof-of-concept, the test works but if we want to do it "correctly" then there are still some things left to do.

Notes:
1.

    And response headers contain
      | Header    | Value |
      | Cache-Control | public, s-maxage=86400 |

In a working Varnish setup this should be something like X-VARNISH: MISS/HIT, but for now it doesn't matter (what matters is that we can verify response headers).
2. This PR passes because it uses Goutte driver (scenarios are not marked with javascript), which also supports response headers.
3. Chromium container can be run with docker run -d --rm -p 9222:9222 --name=chrome registry.gitlab.com/dmore/docker-chrome-headless:7.1 tail -f /dev/null

TODOs:

• find whether Chromium has official Docker images (haven't found any repository yet, if it exists)
• check whether Chromium is faster than Selenium and tests can be adapted to it without too much work. It is said to be: https://gitlab.com/DMore/chrome-mink-driver#chrome-mink-driver
• add support for Chromium in our Docker stack - otherwise we can't run it on Travis

Handled in ezsystems/docker-php#39 and ezsystems/ezplatform#417

• move everything from EzSystems\EzPlatformAdminUi\Behat\Helper namespace to BehatBundle otherwise there is a cyclic dependency between them. Also, this is the right place for these files.
  n similar fashion, map from EzFieldElement should also be in BehatBundle.
• move PageFactory and ElementFactory to BehatBundle, register the rest of factories as services (or simply inject Factory service and use priorities) - same as above.
• merge BrowserContext and UtilityContext - probably iSeeCorrectPreviewDataFor should be in something like FrontendContext (not strictly BrowserContext)

Done in #87 . Factories refactor is postponed for now, does not have to happen yet.

• generate URLs using reverse siteaccess matching - this would add support for other SA matchers then Map\URI, we can skip this point easily for a long time out of scope for this PR

• finish FieldDataProviders to support "parseFromString" - I need to doublecheck the date formats. Also, relations providers need to accept UrlAlias string and convert it to locationId.

Open question:

• how to handle frontend previews (to support custom content types and other templates, in the best case scenario)

I'm still thinking about it, basically I don't think we should rely on hard-coded preview Pages (as we do today), given that this bundle allows to create Content Types basically.
The current approach is "good enough" for now, but should probably be redesigned in the future.