[Research][Solr] Implement Location Search using block join

*!!! Not for code review !!!*

# Research
This is just a bit of research to facilitate further offline design discussions around search in general, and solr data modeling specifically. Started it a few weeks ago out of curiosity to see how feasible it was to get solr search up and running in a state good enough for a first version *(scope: drop in replacement for legacy queries offloading database, but not necessary exposing full solr functionality, and not as a full ezfind replacement yet)*

## Modeling
Locations are indexed as childs of content, which affects queries in the following way:
- For content queries {!parent} is added([example](https://github.com/ezsystems/ezpublish-kernel/pull/1100/files#diff-495351241bc65fb09c8f1193bd61dd47L39)) to location specific criteria.
- For location queries, {!child} is added([example](https://github.com/ezsystems/ezpublish-kernel/pull/1100/files#diff-169c5731e0352bf7a4f19b85d69cd256L40)) on content criteria, and for partial content sort support some content attributes are also indexed ([example](https://github.com/ezsystems/ezpublish-kernel/pull/1100/files#diff-ddac4bd5f1b8eb76e68881917f1905dbL33)) on location document.

## Solr requirements
Uses block join(solr 4.5), and for detecting locations to delete during [->deleteLocation](https://github.com/ezsystems/ezpublish-kernel/pull/1100/files#diff-243a6595df31c391e317e97813109f8cL257) uses _childDocuments_ json indexing support(solr 4.8) and child doc transformer (solr 4.9), both last parts can probably be refactored away.

## Design issues with this approach:
- Only way to get sorting to work asis is to do normalization across parent and child
 - Maybe copyField or other approaches should be used
- Alternative would be to always query content, and use "fl" to query which "location" child to include in result
 - However then you probably won't be able to sort on data on the location "hit"
 - And Content will only show up once even if having several location hits
 - This will need the to know the "context" aka witch root location to use (so LocationQuery->rootLocation is needed)
    
## Current Integration test failures:
- Errors: Caused by Solr and parent/child issues in some queries
- Failures: Repo isn't properly removing subtrees from index on subtree operations
 - This should also be an issue with ElasticSearch unless @pspanja does some tricks ;)

## Alternative discussed during summer camp
During summer camp a (to?) simple solution to most of these modeling issues where discussed, main theme was to drop LocationSearch and instead make sure ContentSearch can provide information about which Locations are relevant for the query. The gist of it API wise can be found [here](https://gist.github.com/andrerom/9f2e93e38840b1e843a0). 


fyi ping @paulborgermans @pspanja