EZP-22564: Elasticsearch storage POC

This implements second part of https://jira.ez.no/browse/EZP-22564

Elasticsearch storage is implemented with quite some shortcuts and a subset of search functionality.

Content and Locations are indexed as separate document types. Location docs have denormalized Content data (Fields excluded) and Content docs have Locations and Fields structured as nested documents. This means full text search and filtering and sorting on Field data is not possible  using Location search. Data is indexed per document, so having it on both Content and Location search would mean doubling the size of index.

Main goal was to implement filtering and sorting on nested documents. Field sort clause is here implemented with all related tests from original SearchService suite passing. Following criterions are implemented:

* ContentId
* ContentTypeId
* LogicalAnd
* LogicalOr
* LogicalNot
* Field (only for EQ and IN operators)
* MatchAll

and these sort clauses:

* ContentId
* Field

Having Fields as nested documents in Elasticsearch keeps the data well structured, while it is also possible to use it for filtering, sorting and faceting. Extracting data from nested docs using _source field should be trivial. Example how the doc looks like can be seen here: https://gist.github.com/pspanja/20a383f9017d725b1563

Having Locations as nested documents of Content is not really required by current search functionality, the same could be achieved with objects. However this has some benefits - it makes Location data well structured and therefore enables more precise custom querying and also future implementation of LocationQuery criterion for Content search if decided needed.

Solr also implements its flavour of Lucene block-join/nested documents, but this does not quite suite our use-case for Fields. In Solr nested documents are full documents, meaning data of nested document is indexed for that document and not for parent document. Aside from that, sorting and faceting on nested docs is ATM not possible. Therefore with Solr, filtering and sorting on Field values would have to be achieved by denormalizing Field data. While entirely possible, it would make querying and extracting data complicated.

### Location search

As mentioned before, full text and Field stuff with Location search is not implemented in this PR. However it is trivial to achieve. It would only require configuring different mapping (schema in Solr speak) and Mapper class.

It could be enabled by default, but aside alternatives for both Content and Location search could be provided. Thereby the user would have some basic control on how to index data and what of search capabilities to use.

### Shortcuts and TODOs

If accepted this PR can be used for implementation of Elasticsearch storage, but here quite some shortcuts were taken. Some of them are:

* mapping (schema) needs to be completed
* FieldNameGenerator needs to be adapted, the one from Solr is only good enough for the case
* Gateway needs to be refactored as it can be shared for both Content and Location search
* Bundle is mostly c/p Solr bundle
* real commit control and bulk indexing needs to be implemented
* probably more...