Features as functions

This PR removes `image.features` and instead makes the feature functions we already had robust to working with menpo images and numpy arrays. This is achieved through using one of three decorators as appropriate:
```python
@imgfeature
def feature_written_for_menpo_image(image):
   # image will always be a Menpo Image
   # must return a Menpo Image.

@ndfeature
def feature_writen_for_ndarray(pixels):
   # pixels will always be a ndarray of pixels
   # must return an ndarray of pixels

@winitfeature
def feature_that_uses_menpos_windowiterator(pixels):
    # pixels will always be an ndarray.
    # I have to return the feature ndarray and the centres
    # from window iterator. This will be used for
    # correcting masks and landmarks. 
```
The decorators ensure that each of these feature functions can be used in a consistent manor - if you provide a `MaskedImage` with landmarks to any of these you will get a `MaskedImage` back with corrected mask and landmarks - if you provide simply a numpy array to any of these you will get just a numpy array back.

A nice consequence of this design is that any features we expose from Cyvlfeat can be instantly made usable in the fit framework by simply adding the `@ndfeature` decorator to them.

This part of the work is fairly small, but it has some large consequences for the fitmultilevel module. Currently there is a lot of machinery in fitmulitlevel that deals with checking and applying features. This is massively simplified in this PR, but it does mean a fairly large change set, so we will need to be vigilant for problems.

This PR is not yet ready, but I need to give something at GOSH my attention for a few days so I thought I would put it up so that people can start reviewing. I've listed what I think needs doing at the end of the PR, and will work through these in the next few days.

Hit me with any questions!

### TODO
- [x] Unify feature checking between SDAAM, SDM, AAM
- [x] Add wrapt to setup.py
- [x] investigate fitting issues on AAM (constrain_landmarks_to_bounds?)
- [x] Decide how to handle constrain_landmarks_to_bounds in fitmultilevel
- [ ] Unit tests for new feature decorators
- [ ] Fix Menpo notebooks
- [ ] Documentation of feature API (maybe in user guide?)

### Key Changes:

1. `menpo.image.features` moved to `menpo.features` (in keeping with not having deeply nested namespaces)
2. Features are now functions that take as a first argument an `ndarray` or menpo `Image` instance. The return type of the function must match the type of the first argument.
3. Feature functions  **have to be decorated with one of three special decorators** - `@imgfeature`, `@ndfeature`, or `@winitfeature`. The choice of decorator is made based on the input type of the first argument of the function. Users can choose to write features that take Menpo `Image` instances - these functions must be decorated with `@imgfeature`. If users wish they can just work on numpy arrays - in this case, decorate the feature with `@ndfeature`. Finally, for the special case of functions that work as part of the Cython Window Iterator framework, use the `@winitfeature` decorator.
4. After decoration, all features will efficiently work with either numpy arrays or Menpo `Image` classes. The return type to the user will match whatever type is provided. If an `Image` is provided, landmarks will be automatically adjusted. If a `MaskedImage` is provided, it's `.mask` is automatically corrected by the framework.
5. Features can no longer have `Image` specific functionality (such as `constrain_landmarks_to_bounds` as a kwarg) as all features have to work on plain numpy arrays as well.
6. Features are performant. Using an `@ndfeature` on an `ndarray` only adds a tiny overhead over an undecorated function.
7. End users are encouraged to make specialised features 'on the fly' - in notebooks for example. These will work just as well in the `fit` framework as 'native' Menpo-provided features.
8. Common features are provided for end users at `menpo.feature.somefeature`.
9. `functools.partial` can be used to customise a feature for use in a framework, by providing a configuration of kwargs. For example: `sparse_hog = partial(hog, mode='sparse')`
10. `img.features.afeature()` is removed. Use `afeature(img)` instead.
11. The `fit` framework is considerably simplified in light of these changes. Validation code for features provided to the fit package is unified and simplified.