Store Content in Solr

# Store Content in Solr

This is a naive approach to store the content objects in Solr by just serializing them into a binary field and unserializing them on load. Using this approach does not require the ContentHandler on load any more. The database will not be used for a simple search.

But this approach has at least two drawbacks:

1) If additional languages are configured between indexing and loading, those fields will not exist. They might be added by the API layer, though.

2) If default values configured in content-types change between indexing and load, those values will not be updated. But this is true for the legacy storage, as well, right?

Both problems can likely be fixed by using the eZ\Publish\Core\Persistence\SqlNg\Content\FieldHandler which strips out not-required fields and populates them again on load from the content-type and language configuration. But since the sql-ng branch is not merged yet, we cannot easily use it without duplicating the effort here.

## Additional Problems

There might be additional problems using this approach. There might be more problems … the integration tests do not find any yet, though.

### Outdated Index

If we have outdated Content in the Solr index, the problem might have been reported on load, earlier, since outdated Content would be fetched from the database. (Solr stored content-id and version) Now it will probably be reported, if we try to update the fetched Content in the database again.