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``

Thanks!

> 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.

I agree. The extra parameter on process_image is annoying (because most filters just ignore it), but I think it's a necessary evil if we want to get this feature out before the forthcoming images refactor. In general terms, the root of the problem is that the filter interface works on image files, and image files by themselves do not encompass all of the image state that the filter might need in order to do its job (because they don't include focal point data). Ideally, we would change process_image to accept an image object that *does* encompass all the state we need - such as a wagtailimages.Image instance (or more likely, a non-django-model counterpart of it) - and then each filter would inspect whatever properties it needs. But that's a job for a full-scale refactor, and passing focal_point separately is an appropriate stopgap solution.

> **focal_point fields on Image class** -- Theres two main reasons why I decided to add the save the focal point on the image

Yep, I have no objections there - it makes sense for these to be fields on the Image record.

> **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

OK. The reason I'm personally not keen on this change is from the angle of "what sort of precedent does this set for future development?". It's effectively saying: whenever you have some image state that might conceivably change over the lifetime of the image and invalidate old renditions, you should load that image state into the cache keys (and filenames) so that you don't have to deal with cache expiry via the 'formal' route (i.e. firing off signals to the cache layer).

At some level I can see why you want to avoid formal cache expiry (fewer 'moving parts') - but it doesn't *feel* like the responsible thing to do in the general case. The one concrete example I can give is this: if we added the ability for users to upload new image files to replace old ones in situ, then following the lead of this change, we would need something like a hash or datestamp to do the cache-busting.

Having said that, though, I have no reason to believe that the amount of image state (= complexity of the cache keys) will grow indefinitely, so I'm slowly coming round to the view that this is more of an aesthetic objection, rather than one with real consequences for Wagtail in the long run.

OK, enough rubber-ducking. I'll accept it :-)