Groundwork for dense correspondence pipeline

This PR contains general improvements and additions to Menpo that are needed for the correspondence pipeline that will be a follow-up PR.

I've decided to split the work as everything presented here is general and useful outside of the scope of the correspondence framework. It should be straightforward to review all this code in isolation and once we are happy it can be brought in.

The correspondence PR actually won't be very large - this really contains the necessary tooling - all the correspondence package will do is string it all together in an easy to use way.


Idea is: when importing another asset from within this package (here, `menpo.shape`) use relative. If you need something from another Menpo package, use absolute. 

Motivation being clarity of namespacing. If you have an absolute import you should always respect Menpo's API placement of classes and functions, not their actual full path 
```
from menpo.shape import TexturedTriMesh
```
not 
```
from menpo.shape.mesh.textured import TexturedTriMesh
```
This gives users browsing the source code the best chance to not learn bad habits of importing the non-public api. 

Of course *within* a package you may well need functions that aren't exposed from the `__init__.py` (this being a good example) - the import being relative is a hint that this is internal API that is being imported. Furthermore, you can run into nasty import issues if you rely on the external API placement from within a package.

This is all up for debate but is the current scheme used so this is consistent. Wouldn't be hard to have a PR where we change everything to be consistent one way or another (for instance, we could look at lazy loading a lot more of the code to cut down on initialisation time).