extraColors option
Limit the precision for custom colors

Using full double precision for storing colors makes no sense.

Truncating to 6 decimals yields a 60 bit (3 (RGB)  * 20 bit and 2^20 ~ 10^6)
color space while very high-end applications only use a 48 bit color space,
which would be about 5 digits.

E.g. regular Photoshop CS6 supports up to 32 bit RGB color spaces, so
clearly, 60 bit is already way overkill, but it reduces the clutter by half
in the color definitions.
extractColors -> dealColorDefinitions
dealColorDefinitions shortened

cellfun with deal instead of for loop
iscolordefinitions: vectorized and shortened
Color mixtures implemented

Basic idea behind it is to run over all defined colors Ci and Cj
and find a value of `p` that reconstructs rgb as Ck according
to the color mixing equation of xcolor.sty

I.e. in xcolor `Ci!P!Cj` with P = 100*p means

    Ck = p*Ci + (1-p) * Cj

or, equivalently:

   Ck - Cj = p*Ci - p*Cj = (Ci - Cj) * p

This can be solved for `p` in MATLAB using:

   p  = (Ci-Cj) \ (rgb(:) - Cj);

where `rgb` is approximated by `Ck` in these equations.
We round the value of `p` to a percentage, as in xcolor.sty and see
how well the approximation of `rgb` by `Ck` holds in infinity norm sense.
This should yield a more conservative guess than the two-norm/least-squares
solution that is computed by the backslash operator.
But the infinity norm `max(abs(Ck-rgb))` is easier to compute and comprehend
than the actual two-norm `sqrt(mean((Ck-rgb).^2))`.
Practically, it means that for some colors `rgb`, there might be a close
approximation `Ck` that is rejected due to one of its RGB components being
off by a lot. So when in doubt, a color is defined instead of mixing two others.
Reordered colors

Put white and black first: most common, so easiest to compose with

Problem: Since e.g. the gray colors are a linear combination of
black and white, those will never be chosen as such. We also need a way of
prefering a color above any of its mixtures
Prefer predefined colors above mixtures
Removed unused branches

We check for exact color matches before the mixtures, so
we shouldn't get `p=0` or `p=1` matches anymore as those
are already caught by the exact match.

Conflicts:
	src/matlab2tikz.m
Using 60bit RGB color space for color mixing

For color definitions, an arbitrary and conservative precision of about
 61 bit was used for the color space. This amount to 20 bit per component.

So, for mixing two colors, this is also the tolerance we should use:
 20 bits per RGB. Together with the infinity norm, this gives a nice
 interpretation for the colors that are obtained using mixing.
 The mixed colors are only accepted if there is not another color
 within the 60 bit RGB color space that (e.g. a shift of 1 least-
 significant-bit on either component) approximates the original color.
 That 60 bit color space is used to write out the custom colors,
 so that effectively means that the mixed color is only accepted if
 it is as good as writing out the color as a custom one.

Again, this is really conservative:

 * 60 bit color space is really big. You just won't believe how vastly,
   hugely, mind-bogglingly big it is. If you want an idea:
   Adobe Photoshop (R) supports up to 48 bits.
 * And given that the mixing happens using percentages (i.e. 2 digits
   or roughly 6.5 bits precision), this is quite a small subspace
   that is accessible.
Color depth/precision into `m2t` structure

Color Depth defined in `m2t` structure. Depending on this,
the color precision (numerical) and the corresponding string format
per (RGB) component is calculated.

As before, 60 bits was chosen, which is 6.02 digits of precision.
In this code it is rounded to 7, before it was set manually to 6.
Color depth reduced to 48 bit

60 bit was overkill anyhow. 48 bit is a more reasonable setting
as this is sometimes used in professional software (e.g. Adobe (R)).

Also, it reduces the number of digits from 7 to 5, such that
storage is reduced (and readability of the TikZ code is increased).
This also makes it somewhat easier to make color mixtures, as the precision
is reduced tenfold.
Merge branch 'colors'