Image feature detection

This pull request adds support for feature detection and image smartcropping into Wagtail.

It performs face/feature detection and crops images based on their content.
I'll remove the ``focal_point`` parameter from ``get_rendition``

I agree that we should keep Filters interface as simple as possible. And I really like the way filter objects are not bound to any particular image so a single filter object and process many different images quickly.

In order to do the cropping, the Filter object needs to know the focal point of the image it is processing. I really don't like the idea of adding it anywhere like the filter_spec as this makes filter objects dependent on particular images which defeats the point of having the filter class. So I really think that passing the focal point with the image file on the process_image method is the best place for this to happen. It is an optional parameter so it doesn't break existing API.

While I agree that we should keep schema changes to a minimum, I strongly disagree that we shouldn't implement new features properly because we are worried about the schema changes that would be required. All of our users are aware that Wagtail is in development and I think they would appreciate that they need to occasionally tweak their projects so they can take advantage of new features.

Heres my justifications for the schema changes in this pull request:
 - **focal_point fields on Image class** -- Theres two main reasons why I decided to add the save the focal point on the image
   - Speed - we should cache detected features rather than recalculating every time we generate a rendition (did you see how slow it was with the picture with all the people?)
   - Allows overriding with manual image cropping - Sometimes, the feature detection code does a really rubbish job and theres not much we can do about that. I think that implementing manual image cropping is essential so users can correct feature detection issues. These fields were added to reduce the amount of work required in the future when we implement manual cropping (all we need now is the UI).

 - **focal_point_key on rendition** -- I'm aware that this could be solved by deleting renditions every time a focal point changes. But I decided to go with this way as it gives a few extra advantages
  - Feels more robust -- If images don't get deleted (eg. a crash, or someone editing focal points with a script) the old renditions will never get replaced and a developer would need to go in and delete them manually
  - Works better with caching -- Renditions are instantly updated even if a cache is in use
  - Faster -- No need to delete potentially hundreds of files when someone changes a focal point. I think deletion of obsolete renditions should be done in a background task (like search_garbage_collect)