Patch LCMS threading bug.

LCMS maintains a ContextID for the sake of the allocator callbacks.
In the call sequence through, it was losing this and ending up with
the allocators being called with NULL.

Simple fix.
Update LCMS2 to avoid race condition in Tag handling.

LCMS2 as supplied (in both 2.3 and 2.4 at least) is broken w.r.t
multitasking due to a race condition in the Tag handling.

When a TagTypeHandler is needed, it is looked up from a system table.
The existing code then writes into this table with the ContextID and
calls the handler. This is a race condition if 2 threads are using
the same TagTypeHandler at a time.

The fix implemented here is to copy the TagTypeHandler structure to a
local one, write the ContextID into that, and then call through that.
Fix LCMS threading issue with plugin registration.

When registering a plugin, allocations can be done. This can result
in calls back to the user supplied malloc functions, which assume
that a cmsContext will be supplied. In the current code there is
no way to pass a cmsContext into the plugin registration.

We therefore add a new function cmsPluginTHR that does take such a
context.
Updated changelog
smooth tone curve fixes
Several fixes
Several fixes to cgats parser
Fix cppcheck warnings
8 bit devicelink generation
>Changes from Richard Hughes
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.