Fix threads and cmsFLAGS_CLUT_XXX_LINEARIZATION

Bug: Using threads and cmsFLAGS_CLUT_XXX_LINEARIZATION
Above scenario causes unexpected scattered colours.
The effect can be easily observed by using a threaded conversion and enabling
the cmsFLAGS_CLUT_POST_LINEARIZATION and cmsFLAGS_CLUT_PRE_LINEARIZATION
flags. This was seen in Oyranos' image_display viewer, which uses lcms and
OpenMP threads.

Problem:
The cache inside Prelin16Data::StageDEF is exposed to threaded calls. Thus it
can obtain random values crossing threads, which results in non determined
colours.

Proposed Fix:
The StageDEF Cache is moved to the PrelinEval16() function. A comment on the
Prelin16Data::StageDEF says that cache has
"no limitation of the output number of channels". Thus we have to locally
allocate the StageDEF Cache and release. The impact on transforms without that
optimisation is non existent. However the cmsFLAGS_CLUT_XXX_LINEARIZATION
conversion works now as expected.

Discussion:
Out of my head I see two further strategies to resolve the local data
allocation per pixel transform.
a) architecture the data structures, that per thread caches can be allocated
   and passed through.
b) use different functions with a limited number for
   Prelin16Data::nOutputs <= MAX_OUTPUT_DIMENSIONS
   and for
   Prelin16Data::nOutputs > MAX_OUTPUT_DIMENSIONS
Implement non allocated optimisation of PrelinEval16

As sugested in Fix threads and cmsFLAGS_CLUT_XXX_LINEARIZATION #8aff578b
Discussion b) this change contains a additional version of PrelinEval16
without local per pixel buffer allocation. That might be helpful in
cases, when malloc is pretty slow.