STYLE: Too many blank lines in itkCastImageFilterTest.cxx.

Change-Id: Ib39959c8ef3655f866e73826a58f1f24bee571ce
COMP: Add _CRT_NO_SECURE_WARNINGS when building GCCXML.

Change-Id: If280e8885c2faac5c7b9d1543efda3647dce2cf0
COMP: Bump MINC third party to fix warnings.

Comparison of integers of different signs and unused function warnings.

Change-Id: I3eebec1878e39dfdcdfbacbb74f9886c7e7ee157
WIP: Support Single Precision Numbers in ITK

The current registration framework of ITK just can process data using double precision.
However, in some cases base on our need, using 'float' type is enough
for the computations precision. This allows CPU to process more data
in its cache so increases the computations speed. Also, it needs less
memory when the outputs need a lot space to be written to the disk e.g.
deformation fields.

A) One of the main obstacles to achive this goal is the definition of
"ParametersValueType" in the "itkTransformBase" class, which is hard
coded to 'double'.

This obstacle can be removed by changing the itkTransformBase class to
a template class named "itkTransformBaseTemplate<TScalar>" that TScalar
can be set to 'float' or 'double'.

As the "itkTransformBase" is at the top hierarchy of many other
transform classes, we should be careful to keep backward compatiblity.

Two groups of classes are important in this regard:
1- All transform classes because they are derived from the transformBase
class.
2- All the IO classes that are related to Reading/Writing transforms.

As all transform classes are already defined as a template over 'ScalarType',
the first group of files does not cause any incompatibility issue here.

To keep compatibility for the IO group classes, I have created a
hierarchy of classes parallel to original ones. The classes included
in new hierarchy are defined as a template over internal computations
type.

Therefore, by this method backward compatibility is met. Also, user can
use new set of classes to write a more flexible program than can work
with both singl and double precision.

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

Therefore, I also created a new hierarchy of classes for all Metric and
Optimizer classes as I did for transform IO classes.

A bunch of files are added; The computation type is added as a new
template value called "InternalComputationType". However, some of newly added
template values are called "ValueType". They should be changed
to more proper names like "ParameterValueType" or
"InternalCompuationType".

Notice again that Metric and Optimizer classes are not derived from
their template version.
To keep the backward compatiblity, I have to keep the inheritance
hierarchy; therefore, I made a hierarchy of new template
classes, and I kept the legacy hierarchy independent of that.

Also, all newly added template versions of metric and optimizer classes
are just for ITKv4.

ITK is built completely and all tests are passed after changes of this patch.

Change-Id: If55fcd401fcc9373cba2e0749e27e3c2fa4b2cd1