Memory squeezing bug: lcms2 MatrixElemTypeFree

Destructors should cope with NULL.
Memory squeezing fix: lcms2 cmsPipeline construction

When creating a new pipeline, lcms would often try to allocate a stage
and pass it to cmsPipelineInsertStage without checking whether the
allocation succeeded. cmsPipelineInsertStage would then assert (or crash)
if it had not.

The fix here is to change cmsPipelineInsertStage to check and return
an error value. All calling code is then checked to test this return
value and cope.
Add header file for faster transforms.

Rather than holding multiple implementations of different transform
routines direct in cmsxform.c, we extract the guts of the transform
function out into cmsxform.h. We then repeatedly include that
file from cmsxform.c to create the functions.

The code in cmsxform.h is faster with regard to caching, as it
doesn't do unnecessary copies on successful matches.

But why not just this faster code direct in cmsxform.c? Why go to
the trouble of pulling it out into a separate header?

Firstly, any future changes or optimisations can be applied in just
one place, rather than having to be applied in every place throughout
the code.

Secondly, having the code in a reusable form like this allows us to
trivially create optimised versions. If a given application uses
a particular set of transforms a lot, it is easy for coders to
generate optimised versions simply by including our header multiple
times with the appropriate predefine.

LCMS 2.4 includes some cunning 'transform factory' code to enable
optimised versions to be declared to the library. The use of such a
header to generate functions dovetails nicely with this by providing
the ability to generate such factories simply.
Some simple code for capturing the transforms used.

I use this for figuring out exactly what the different transforms
used by Ghostscript are while running our test suite, and what the
frequency of use of the different transforms are.
Transformation Plugin factory with optimised transforms for gs.

More to come, but this is a proof of concept.