Set YouTube title as the content item's displayName
Fix SlideShare displayName
Pluggable Preview Processors.

This commit introduces a bunch of outstanding preview-processor related bugfixes (#456, #436, #435, #434, #431 and #409) as well as some other improvements.

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.

`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)

 * 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 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.

This PR builds upon the collaborative documents PR and should be reviewed/merged after the collabdoc PR goes trough.
Creating previewsdirectory in initialization life cycle.
change context to principalid for internal api
Notifications use new content-revision event.
Previews refactor: getting and setting previews should pass the revisionId in the REST endpoint
Previews refactor: Using MQ.purge to purge previews.
Previews refactor: Added sanity checks to ImageUtil.cropt tests.
Previews refactor: Signature fix for uri downloads + better preview images for collaborative documents
Previews refactor: Move etherpadHtml to the revision object.
Merged master.
Previews refactor: Ignore collaborative documents who aren't published yet.
Previews refactor: Added etherpadHtml to the Content Profile endpoint (/api/content/:contentId).
Previews refactor: Removed getOrCreateQueue from MQ util.
Previews refactor: Disabled previews.
Merge branch 'master' into previews-refactor

* master:
  Added some JSDoc to _externalSuccessCallback in oae-auth/rest.js and moved the res.redirect('/me') in the logIn block.
  Log logins from all strategies
  add util method for logging authentication success
  quote object keys
  code review issues
  log authentications
  (Issue 466) Add config option to purge rabbitmq queues after connect but before subscribe
Previews refactor: Auto orienting images when resizing/cropping based on their EXIF Orientation.
Revert PDF size change for normal size images as it distorts the image.
Previews refactor: removed unneeded JSON.parse block in dao.revisions,  added the latestRevision on the content document when publishing a collaborative doc + uri fix.
Previews refactor: Only initializing the processors when the preview processor is enabled.