EZP-22564: As a Developer I want Location Queries to be handled by Solr

This PR resolves issue https://jira.ez.no/browse/EZP-22564

Being able to search for both Content and Locations means we need to have two types of documents in the index, for each of the entities. With that given, several options exist in regard to data contained in the documents:

1. denormalize

  Denormalization is the normal approach but the obvious drawback here is size of the index as both Content and Location documents would need to hold all needed data, therefore more or less duplicating everything.

  One possible approach here is denormalizing Field data only into Content documents, therefore disallowing full text search and filtering and sorting on Fields with Location search.

2. (query-time) [Join](https://wiki.apache.org/solr/Join)

  Better than denormalization index size-wise, but has some limitations. It requires documents to reside on same shard for join to work in a distributed environment (possible with document routing). Doing join in query time also has some performance penalties and faceting and scoring is not supported at the moment. It is not possible to sort result set on the fields of joined documents.

3. [Block Join](https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-BlockJoinQueryParsers) / [Nested Documents](https://cwiki.apache.org/confluence/display/solr/Uploading+Data+with+Index+Handlers#UploadingDatawithIndexHandlers-NestedChildDocuments) (aka index-time join)

  Better performance wise than query-time Join but has similar limitations. One other drawback is that blocks need to be updated as a whole, so updating Content means re-indexing all of its Locations and vice versa. It looks like in Solr community this has a bit more attention than query-time Join, so missing features can be expected in next releases. (FWIW here Elastic Search already has support for sorting on nested documents fields)

Location search this PR is implemented using Block Join. For some sort clauses to work some Content data is denormalized into the Location documents (note that the opposite is not the case as we deprecated Location sort clauses with Content search). Fields are not yet denormalized as we have some open questions there.

Content Search Handler and its gateway are adapted for indexing document blocks. This also required implementing `CreateLocation` signal and adding `$contentId` property to the `Trash` signal.

### TODOs

- [ ] Discuss the whole approach here, particularly in regard to future changes to Field data indexing