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.  Small test case showed
30% speed increase.  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 gigabytes of memory disk. An example of
such outputs is transforms files that contain several deformation fields.

This required many 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.

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
Merge topic 'SinglePrecisionAddedToITK'

73c1b61 STYLE: Replace expected exceptions with macro
5e73533 STYLE: Simplify H5::Exception handeling
593dfbd STYLE: Avoid polluting the ITK namespace
4c6775b ENH: Support single precision registration
dc46ba4 PERF: Optimizer scale caching and avoid copy