Previews refactor

This PR introduces a bunch of outstanding preview-processor related bugfixes (#456, #436, #435, #434, #431 and #409) as well as some other improvements.

# Improvements

## Preview Processor Registration Pattern

This is a little bit more flexible and should allow for better third-party integration.
There are now 2 phases that happen after a `generatePreviews` task is received.

The first phase is a selection phase where the correct (or best suited) processor is selected. Each processor is handed the content item and is allowed to do async IO to check whether it can deal with this content item. Each processor returns a number that expresses the suitability match between the content item and the processor. A negative number means `don't use`. The processor that returns the highest non-negative number is selected. If all processors return a negative number, the content is ignored. The default OAE processors return a number from the interval [-1, 10].

The second phase is the actual preview generation process.

## Revisions

`generatePreviews` tasks now contain a `revisionId`. This means that preview images are now associated with revisions rather than content and that revisions will have thumbnails (as per #456)

## Thumbnails

 * For each revision, 2 thumbnail images get generated. The square 162x162 thumbnail and a new flat rectangle one (535x250) that can be used in an activity feed.
 * Thumbnail images in the library, search page and activity feed are served from `/api/download/signed?uri=<..>` rather than the `/api/content/:contentId/previews/thumbnail.png` endpoint. This eliminates 1 Cassandra read query *per* downloaded thumbnail (if a user has 20 thumbnails on the page, 20 cassandra requests are avoided)

## Activity improvements

Activity items no longer dump the entire previews object. The content item's thumbnail and large flat rectangle url are returned. The UI should not be constructing their own URLs to generated preview images. If that would ever happen again, it means we missed something.


### Notes.
This PR builds upon the collaborative documents PR and should be reviewed/merged after the collabdoc PR goes trough.