Fix bug in addCustomCode (after argument is not assigned)
Deal with the case where a Matlab colormap has only 1 colour (as this is not allowed in pgfplots)
Merge commit 'f204e544bf36a123713b8051de724c0d3f0daa30'

Conflicts:
	src/matlab2tikz.m
In matlab2pgfplotsColormap need to deal with the case where the MATLAB colormap has only a single color, which is valid in MATLAB but an error in pgfplots. Simply repeating the single color in the colormap seems to produce the desired effect.
Merge branch 'colormap'
Updated test framework to R2014b-PR
Scatter plots in R2014b

Scatter plots in R2014b (HG2 objects) use different objects which weren't
handled properly.
R2014b: HG2 Group objects handled
handleAllChildren: useful warning when no children

If handleAllChildren was called but no children were present, an obscure
error was returned (bad SWITCH statement) due to children returning []
and hence their type being [] while a string is expected.
So now, [] is being cast to char and the case '' is handled explicitly.
Stem and Stair plots in R2014b
strcmp[i](..., 'none') -> isNone

Used `isNone` everywhere.
R2014b bar objects

Mostly handled, only the colors remain way off.
For now, just the structure will have to suffice, as finding the "flat" color
(which is interpreted in the colormap) is not as straightforward as expected.
R2014 error bars
R2014b area fixed, "flat" color mode fixed
Quiver R2014b added

In R2014b, the line series with explicit coordinates is no longer present.
This means that it was necessary to re-implement the scaling algorithm of MATLAB
Consequently, the previous shortcut has been removed, making sure that the code
base is equivalent for the different versions of MATLAB.

The output from the ACID tests (23 and 25) looks fine from R2014b. Older
versions have not yet been tested, that will happen right before merging this
branch into master
empty str in handleAllChildren
Explicitly cast mixing percentage to an int

There is a very occasional bug in which matlab seems to ignore int format specifiers and print in exponential notation instead (i.e. printing 'red!5.500000e+01!mycolor1' instead of 'red!55!mycolor1'). This breaks xcolor, which doesn't parse this notation. Since p*100 is a percentage in the range [0,100], it is safe to cast this to an int and guarantee that matlab will correctly output the mixed colour.
Use `round` instead of `uint8`.

More sure that `round` works properly accross platforms and versions
than `uint8`.
Merge branch 'theswitch-patch-1'
Merge commit '531759ea1f2f805c5b2ec975ee93dc15fff84184'