ENH : modifying the reader and writer to get 3D vector iamges instead of 4D scalar images (in 3D)

* LDDMM, writing transformation map :
writeFileITK( ) has been edited, in case the voxel-stored data dimension is the same as the image dimension, to write a DeformationImageType [1] instead of the CalaTK ITKVectorImage object [2].
For example in 3D, it was writing a 4D scalar object instead of a 3D vector object.
To give to the writer the good parameter, we had to modify convertToITK( ) to return a DeformationImageType from the VectorImageType given.
=> ISSUE : Even though unu head on the written file or print() the DeformationImageType seem to give us the new structure we were looking for, we can not visualize this displacement field or use it with our current tools.

* applyMap, reading transformation map and writing computed image :
We should not have to modify writeFileITK( ) anymore since it was making the distinction between scalar image and vector image ( line 2473/2502 VectorImageUtils.txx )
The only thing we had to do was therefore change the reader to make sure it would be able to convert the DeformationImageType written with LDDMM into this VectorImageType in CalaTK.
readFileITK( ) was therefore modified to read the file as a DeformationImageType and not a ITKVectorImage.
After this, we had to modify convertFromITK( ) so that it would create this VectorImageType from a DeformationImageType and not ITKVectorImage. I used the inverse method used in convertToITK.
=> ISSUE : output file is written as a 3D vector image instead of a 3D scalar image. This should not happen even if we know that there might be an issue with the transformation map we are reading.

[1] DeformationImageType
typedef itk::Vector<T,VImageDimension> DeformationPixelType;
typedef itk::Image<DeformationPixelType, VImageDimension> DeformationImageType;

[2] ITKVectorImage
struct ITKVectorImage { typedef itk::Image< T, VImageDimension + 1 > Type; };
ENH : reader dependent of map or image + save map as displacement field

- ReadFile becomes readImage and readMap, each of them calling a different convertFromITK
- HFieldtoDeformationField is used to write the map vector field as a displacement
- DeformationFieldtoHField is used to read the map vector field and convert it as a HField
ENH : include space direction and origin when writing/reading maps
- the conversion from the Hfield to the displacement was not enough since the Hfield only included spacing information, and not space direction and origin information
NEW : check if input images have same header information
NEW : use CHeckIfSameHeader() in applications
- used in GeometricMetamorphosis, LDDMM, & MetamorphosisShooting
ENH : new parameter in writeFileITK to choose if Hfield or displacement

- add a boolean parameter to writeFileITK to choose if the Hfield needs to be converted to displacement field when dealing with writing a deformationfield
ENH : transform writeFileITK() into writeImageITK() and writeMapITK()

- Just like for applyMap where we separated the reader for a deformationfield and for an image, we do the same here
- We add the boolean parameter writeAsDisplacement to writeMapITK() which will indicate if we do or not the conversion with  HfieldToDeformationFieldFilter()
BUG : use writeImageITK() and writeMapITK() instead of writeImageITK() in applications and libraries

- for applications like GeometricMetamorphosis, LDDMM and MetamorphosisShooting, we added the boolean bWriteAsDisplacement that would be TRUE with the flag --writeAsDisplacement in the XML files, and used this value in writeMapITK()
- IMPORTANT : I don't really know how to set this boolean value (writeAsDisplacement) for the writeMapITK() in the librairies (objectiveFunctions, States, ImageManager and Algorithms) :
-- for the objectiveFunctions I assumed it should always be on false because this is inner processing within CalaTK
-- CStateInitialMomentum & CImageManager : No idea
-- CLongitudinalAtlasBuilder : I am wondering if it should not use a value set in the XML file of the Application "AtlasBuilder", and pass to this Algorithm
- IMPORTANT 2 : a LOT of writeFileITK have been replaced, errors could have occurred like using writeImageITK instead of writeMapITK or the other way around
- IMPORTANT 3 : the tests have not been updated for the replacement of writeFile
ENH : bool parameter to do conversion when readMapITK()

- using bReadAsDisplacement in the XML file of ApplyMap to choose if the conversion is needed in readMapITK()
NEW : adding CheckIfNewHeader in ApplyMap

- the method is going to compare the source image and the sourceToTargetMap
- the Map has one more dimension holding the deformation vectors, but this dimension is written after the space dimensions. Therefore, when checking the header, it's going to compare the good first dimensions and stop before the deformation field.
BUG : allowing small relative differences ( < 1.0e-6) for inputs spacing

- when using LDDMM, we encountered a difference between the spacing of the Map computed and the spacing of the source image ( 0.019999999552965164 instead of 0.02). This allows to use CheckIfSameHeader in applyMap if the difference is small enough.
Merge branch 'newReaderWriter'