Fixes from coverity check
Fix some warnings from static analysis
Fixed a minor overrun chance
Upgrade autotools
Added linear gamma to unbounded mode capable
Get rid of dummy NEWS file
Added ABGR formatter
Richard Hughes additions
Fix for multitherad opt
Updated BPC algorithm
Cosmetic: fix some typos.
Merge pull request #11 from Underground78/typo_fix

Great job, I'm pulling it.. thanks!
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.
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.