ENH: Update build system to more robustly check bitness using void ptr size

This commit update the build system so that void pointer size is used
instead of system process name.

[CTK]

$ git shortlog 9e8f66f..f34158 --no-merges
Jean-Christophe Fillion-Robin (1):
      Check bitness using void ptr size instead of system processor name

[DMCTK]

$ git shortlog f461865..042de27 --no-merges
Jean-Christophe Fillion-Robin (1):
      Update CMake build system to more robustly check bitness using void pointer size

git-svn-id: http://svn.slicer.org/Slicer4/trunk@23805 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: Update python - Fix configuration error on 32-bit system of type i686

The commit fixes the following error:

// ---------------
CMAKE_SYSTEM_PROCESSOR:i686

/home/thiele/Slicer-SuperBuild-Debug/python-build/../Python-2.7.3/Modules/_ctypes/libffi/src/i686/ffi.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx
Call Stack (most recent call first):
  cmake/extensions/CMakeLists.txt:183 (add_python_extension)

// ---------------

[python]

$ git shortlog 47845c5..ee53f79 --no-merges
Jean-Christophe Fillion-Robin (1):
      Fix configuration of ctypes extension in case system processor is i686



Thanks to  "Thiele Kobus <TKOBUS@partners.org>" for his help identifying
the issue.

git-svn-id: http://svn.slicer.org/Slicer4/trunk@23806 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Fixed composite transform problems

By hardening a non-linear transform on a vtkMRMLLinearTransformNode makes the contents of the linear transform node non-linear. This causes errors in many places in the code where linearity of the transform is tested by checking the class type instead of calling transform->IsLinear() or transform->IsTransformToParentLinear().

In the long term all specific transform nodes (linear, bspline, grid) should be removed and only the generic vtkMRMLTransformNode should be used everywhere. The specific classes are already “empty”, they do not contain any useful functionality, but they are be used in extensions (and still have not removed from everywhere in the Slicer core), so they have to be phased out gradually.

Specific problems:
* If affine transform is applied to bspline then bspline component is ignored
* If affine transform is applied to bspline and affine is hardened then the bspline component is lost.
* Hardening multiple nonlinear transforms on a transform sometimes results in incorrect composite transform

Fixes:
* Instead of casting to vtkMRMLLinearTransform IsLinear or IsTransformToWorldLinear has to be called to decide if a transform is linear (checking the class type does not work correctly for composite transforms)
* Fixed vtkMRMLTransformNode::ApplyTransform
* Moved full implementation of get/set transform matrix functions in vtkMRMLTransformNode (it further prepares removal of obsolete linear/bspline/grid transform node classes)

Enhancements:
* Allow splitting of composite transforms to its components (Transforms module: Split button – only displayed for composite transforms)


git-svn-id: http://svn.slicer.org/Slicer4/trunk@23807 3bd1e089-480b-0410-8dfb-8563597acbee