COMP: Revert use of itkLegacyMacro

The itkRigid3DTransform class was intended
to be an abstract base class for Rigid Transform
child classes that adds constraints to the SetMatrix
funciton.

In ITKv3 this class was often mis-used.  In our attempts
to maintain backwards compatibility/warn on use of legacy
code, and provide a forward clean path for ITKv4 this
base class has become very difficult to set the proper usage
on member functions that is compatible with all the desired
compilation options.

When ITKv3 compatibility is selected, the GetInverse and
GetInverseTransform functions must be traversed from
child classes, and are therefore part of protected interface
that can not be designated as itkLegacyMacro (otherwise warnings
are issued even though they are not called directly).

In ITKv4, they do not need to be defined at all because
they can simply use the MatrixOffsetBase class version
of those functions.

Change-Id: Id0651d1ecc5ada38470f139325883065e5e2cc53
Merge topic 'FixRigid3DCompilerWarnings'

072b6ee COMP: Revert use of itkLegacyMacro
COMP: WrapITK generates non-unique typedefs in FFT submodule

This topic is is intended for the release branch.

CMake generates the typedefs for wrapping support in
Wrapping\Modules\ITKFFT whereas these typedefs are not unique.

Aditionally I've found out that the underlying FFT implementation
supports only up to 4 dimensions.

To get rid of errors that are generated during compilation if
ITK_WRAP_DIMS are e.g. 5 or 6 an if construct was implemented.

Enable the instatiation of complex of double pixel by correcting the
itk_wrap_template types for FFT filters.

Change-Id: Ib639eddae51ec09f7f1cd37e02cdf58f1332ac63
COMP: fixing error when instatiated with image of double

This patch is for the release branch.

Addressed compilation errors when images of double are turned on for
wrapITK.

Change-Id: I04c11dfd183dadbb7b9bdee13533365fba12ee7b
PERF: Pull expensive GetInput/GetOutput calls out of inner loops

Between ITK3 and ITK4 a new scheme was set up for managing filter
inputs and outputs by name instead of by index.  This has made
the GetInput & GetOutput methods much slower. This has had a
serious performance penalty in several filters who call these
functions in inner loops.  In some cases this is a
straightforward fix, in others the input and output handles need
to be cached at the class level.

The fixes in this patch were accomplished by instrumenting the
ProcessObject methods and throwing an exception if they were
called an unreasonable number of times.  I started with a
threshold of 100,000 and after an initial pass, decreased this to
2000, at which point 'false positives' showed up.

Outstanding Issue:

PipelineMonitorImageFilter::PropogateRequestedRegion
Test Failure: itkJoinSeriesImageFilterStreamingTest
Solution: Cache pointers to input and output
Problem: Not sure where these could be initialized in such a way
that they would be updated if the input or output changed.

BinaryFunctorImageFilter::ThreadedGenerateData
Test Failure:  itkLabelMapContourOverlayImageFilterTest2
Solution: Cache input/output, possibly in BeforeThreadedGenerateData
Problem: I suspect that the test failure arises more from the
re-use of an instance of SubtractImageFilter, than any actual
problem of over-use.

WarpVectorImageFilter::GenerateInputRequestedRegion
Test Failures: itkDiffemorphicDemonsRegistrationFilterTests
(those numbered 01,02,03,04,05,06,07,09,10,11)
Solution: Not clear if one is needed; or if a simple fix is
possible.
Problem: itkExponentialDisplacementFieldImageFilter::GenerateData
uses a sort of a mini-pipeline; in a loop it re-uses the same
instance of WarpVectorImageFilter.  This racks up the count of
calls to GetInput/GetOutput in
WarpVectorImageFilter::GenerateInputRequestedRegion. It might be
good to go back and re-examine how this filter is built.

Change-Id: I2a92882098be6e8d026ff92d3de057f049b55cc7
COMP: WrapITK generates non-unique typedefs in FFT submodule

This topic is is intended for the release branch.

CMake generates the typedefs for wrapping support in
Wrapping\Modules\ITKFFT whereas these typedefs are not unique.

Aditionally I've found out that the underlying FFT implementation
supports only up to 4 dimensions.

To get rid of errors that are generated during compilation if
ITK_WRAP_DIMS are e.g. 5 or 6 an if construct was implemented.

Enable the instatiation of complex of double pixel by correcting the
itk_wrap_template types for FFT filters.

Change-Id: Ib639eddae51ec09f7f1cd37e02cdf58f1332ac63
Merge topic 'wrapITK-FFT-bugfix'

aae6b9a COMP: WrapITK generates non-unique typedefs in FFT submodule
Merge branch 'release'

Conflicts:
	Modules/Filtering/FastMarching/include/itkFastMarchingExtensionImageFilter.hxx

Change-Id: I4c38f2b38c2efe763571894e7e9356c5b2212d12