BUG: Assert unchanged pixels only for non-PALETTE_COLOR images

Change-Id: I1781cf8cdcaf26a54311bf1bd7e2338230465e70
BUG: Add test case for GDCMImageIO

Change-Id: Ifd9bdc15145d47e0c2a2edd6d43e454152296f33
PERF: Optimizer scale caching and avoid copy

PERF: The inverse of the scales was recomputed at each iteration
during the scaling process.  Cache the inverse values and use them
directly.

BUG: Zero scales should not be supported.  In the optimizers
a parameter scale of zero would result in a division by zero
in the parameter space.  This should be checked and an exception
thrown at the time of setting the parameters.

BUG: vnl optimizers may have a different type than the ITK parameters.
There is an InternalParameter type that should be used for parameters
that are propogated to the vnl_optimizers.

Change-Id: I4353d912f976ee4a6154b3c6b98b0b4d971bb04b
ENH: Support single precision registration

This is work related to https://issues.itk.org/jira/browse/ITK-108

The current registration framework of ITK just can process data using double
precision. However, in some cases using 'float' type is enough for the
precision of computations.

This feature allows CPU to process more data in its cache in a limited
period of time, so it can increase the computations speed.
Also, writing outputs to the disk using single precision needs much less memory
rather than we save them by values in double precision.
Saving the memory space is specially important when our outputs are huge
files that need hundreds of giga bytes of memory disk. An example of
such outputs is transforms files that contain several deformation fields.

We need a lot of changes in several files of ITK to make that consistent
with this new feature.
The following provides a short describtion of the main obstacles and the
ways that are used to tackle them:

I) One of the main obstacles to do the compuatations in single precision
is the definition of "ParametersValueType" in the "itkTransformBase" class,
which is hard coded to 'double'.

This issue can be solved by re-definition of the itkTransformBase class as
a template class over the internal computation type e.g.
"itkTransformBaseTemplate<ParametersValueType>". The template parameter
can be set to 'float' or 'double'.

Also, to keep backward compatiblity, we define the original
TransformBase after the definition of this new template class as:

>> typedef TransformBaseTemplate<double> TransformBase;

At the next levels of the hierarchy, we are not worried about the other
transform classes because they are already defined as a template over
the 'ScalarType', so the backward compatibility issues are automatically
solved for them.
Also for the IO classes that are related to Reading/Writing transforms,
we use the same procedure used for TransformBase class.

While backward compatibility is met, we can use this new set of classes
to write more flexible programs that can support both single and double precision
for their internal computations.

II) The second main obstacle is that "ParametersValueType" is hard
coded as 'double' in "itkCostFunction" base class.

Therefore, I changed all the Metric and Optimizer classes the same way that
I did for transform IO classes.

All these classes are modified in a way that minimum changes be needed
from the original version of ITK.
In many of them just a new template parameter is added as
"InternalComputationType" that is set to double as default.

PS: The new template versions of metric and optimizer classes are just
added to ITKv4.

Change-Id: If55fcd401fcc9373cba2e0749e27e3c2fa4b2cd1
STYLE: Avoid polluting the ITK namespace

Global variables that can be shared across template
instantiations can be a private class/struct
and use multiple inheritance where ONLY ONE public interface
is exposed.

This was inspired by work done by Brad Lowekamp in the
common class that is multiple inherited such as was done here:
https://github.com/Kitware/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L87

Change-Id: I7f2bd15829772d0694c2dc35ce0d0d21595847f3
STYLE: Simplify H5::Exception handeling

H5::Exception is a base class for exception
handeling types.  There is no need to have
a cascade of H5::{specialized_type}Exception
catch'es, only one catch on the H5::Exception
is needed.

Change-Id: I429aa49cf0dd3f5549b7032f625f3b06703ccf8e
STYLE: Replace expected exceptions with macro

Use the common exception macro for handling expected exceptions.

Change-Id: I3d82b074e1ef47c499c1e650ca855d8ee53bb10c