When switching the shape and blendshape fitting to use the new Eigen models, these matrices weren't correctly mapped to cv::Mat. Eigen uses col-major storage order by default, and OpenCV row-major - so we now convert to a row-major Eigen matrix before mapping to a cv::Mat.
This caused the fitting to produce faulty/meaningless results since the switch to Eigen.
The output of the linear shape and blendshape fitting functions are now again identical before and after the switch to Eigen. (after 50 iterations, the result is marginally different, most likely because of small rounding differences.)

* ImageCost throws on instantiation if the given model doesn't contain a colour model
* Changed the default parameter of fit-model-ceres to sfm_shape_3448, which will need to be obtained
* Additionally the app checks explicitly for has_color_model() and will exit if it hasn't got one.

Otherwise an Eigen expression (CWise...something) will be returned and subsequent code will fail.

This fixes a crash - it should obviously return a matrix, not a vector.

Install if the Eigen from the submodule (3rdparty directory) is used. This is the case, except when a user specifies their own EIGEN3_INCLUDE_DIR - in that case, we don't want to install the headers.

Travis only has Eigen-3.2.0, while the new pybind11 Eigen bindings require 3.2.7 as minimum.

The submodule is used by default, and EIGEN3_INCLUDE_DIR should only be set if a user has an explicit need for it.

As we now include Eigen as submodule, we're using the one (identical) under 3rdparty/eigen/cmake.

The new pybind11 bindings require at least Eigen-3.2.7. Travis and Ubuntu 14.04 only include Eigen-3.2.2, so let's include Eigen as a submodule.
Unfortunately Eigen uses Mercurial and no official git mirror exists, so I've cloned Eigen's mercurial repo and added it at patrikhuber/eigen.git at version tag 3.3.3.

This includes their new Eigen3 bindings

This seems to be unused (uninstantiated) code, and only clang complains, but not MSVC & gcc.

This removes the last usage of OpenCV in PcaModel.

It's no longer necessary, since the RNG is no longer part of PcaModel.

This makes the intent clearer - it does not return the i-th basis vector (which one could easily assume, if not reading the function parameter name or documentation).
Also added a note expressing this.
It also leaves room for a future function that actually does return the i-th basis.

And compute the rescaled basis when loading a model.

Adjusted all files that use it (hopefully).

This is a breaking change: If you're currently using the PcaModel constructor and giving it a PCA basis matrix, your code will (probably silently) break: The function now expects an orthonormal basis matrix, whereas before, it expected a rescaled basis matrix. However it makes more sense for the function to take an orthonormal basis matrix.

This should clear up confusion and make the descriptions good and unambiguous.

- orthonormal = the old "unnormalised"
- rescaled = the old "normalised".

Also changed PcaModel's getter for the basis accordingly, and updated the documentation.

Both the BFM and SFM store the orthonormal basis in their files. The orthonormal basis is what eos calls "unnormalised" (because it's not rescaled by the eigenvalues).
We will get rid of this ambiguous terminology in eos now and use the unambiguous terms:

- Orthonormal basis (previously "unnormalised")
- Rescaled basis (previously "normalised).