BUG: Ensure ITK IOFactory are registered for EXECUTABLE_ONLY cli modules

The library wrapper are now used when compiling either the [executable] or
[executable + shared library] cli module. It allows to call the
"itk::itkFactoryRegistration();" in both cases.

Associated SlicerExecutionModel commit is:

// ---------------------------------------------------
ENH: Use library wrapper in the "EXECUTABLE_ONLY" case
This will allow custom wrapper to execute some code before the main
entry point in both the [exec + shared lib] and [exec only] cases.

The macro "MODULE_STATIC" has also been introduced and can be tested
within the wrapper to discriminate both cases.

Change the component associated with Archive target from RuntimeLibraries
to Development. That way, static library won't be packaged.
// ---------------------------------------------------


See http://na-mic.org/Bug/view.php?id=3008
Fixes #3008

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

* Add qSlicerFileDialog::description
* Add input dialog to select reader when multiple readers accept the same mime data


How to create a FileDialog in python?

+class XYZFileDialog:
+  def __init__(self, parent):
+    self.parent = parent
+    parent.fileType = 'XYZ'
+    parent.description = 'XYZ'
+    parent.action = slicer.qSlicerFileDialog.Read
+  def isMimeDataAccepted(self):
+    accept = self.parent.mimeData().hasFormat("text/uri-list")
+    self.parent.acceptMimeData(accept)
+  def dropEvent(self):
+    self.parent.dropEvent().accept()
+  def execDialog(self):
+    print 'exec'

How to order the list (make the module reader by default):
Make the module depend on "Data" -> instantiated after "Data" module
   def __init__(self, parent):
+    parent.dependencies = ["Data"]

Issue #3081

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21951 3bd1e089-480b-0410-8dfb-8563597acbee
ENH: #2761 Add CTCTDentalSurgery example

One click to get pre- and post- surgery scans, but the
logic API allows access to individual scans if desired.

http://na-mic.org/Bug/view.php?id=2761

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21952 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: fix duplicate metatype declaration (Issue #3081)

See also r21951

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21953 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: QInputdialog does not exist - changed it to QInputDialog

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21954 3bd1e089-480b-0410-8dfb-8563597acbee
BUG: Skull stripping in test mode did not work

git-svn-id: http://svn.slicer.org/Slicer4/trunk@21955 3bd1e089-480b-0410-8dfb-8563597acbee
COMP: On MacOSX, do not create duplicate of MRMLIDIOPlugin and MGHIOPlugin

This fix MacOSX warning "/path/to/plugin is already loaded"

Both MRMLIDIOPlugin and MGHIOPlugin were copied so that it exists both
a "dylib" and a "so" version of the file. This was initially committed
on the 2007-09-27 to work around a limitation of ITK preventing it from
loading plugin having ".dylib" extension. See Slicer3 r4454 [1]

Then 2 months later, on the 2007-11-19, a fix has been pushed in ITK so
that plugin having extension "dylib" are considered. See ITK commit 28b4a6ba [2]

This commit account for the ITK fix by removing the code in charge of
copying the plugin.

Lessons learned: When implementing a hack, it is a good practice to report
a bug upstream to track the limitation and also reference the bug in a
comment starting with either "# HACK" for CMake file or "// HACK" for
c/cpp files. It would give a hint to developer re-factoring the code.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer3?view=revision&revision=4454
[2] https://github.com/Kitware/ITK/commit/28b4a6ba
ENH: Move MacOSX configuration code for CLI factory to a better place.

As a slight improvement, the path is also appended only if it exists.
ENH: Simplify logic by appending path to CLI factory only if they exist.
STYLE: Do not check for version of CMake before including "BundleUtilities"

Since minimum required CMake version for Slicer is 2.8.9, this message
is not needed anymore.
COMP: Ensure Python library directory is considered when fixing up package

When the expression "@SLICER_PYTHON_LIB_DIR@" has been introduced
in commit r21252 [1], it was already resolving to an empty
string because since r15463 [2] the file SlicerBlockCTKAppLauncherSettings is
included in the Applications/SlicerApp/CMakeLists.txt.

Both the fixup script and the launcher settings have been updated to
use the variable "PYTHON_LIBRARY_PATH" introduced in the top-level
CMakeLists.txt by commit r16822 [3]

To prevent such error from happening again, a convenient macro named
"_fixup_paths_append" has been introduced. It basically check if the path
passed as parameter exists and append it to the list of paths. If not,
it throw an error.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21252
[2] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=15463
[3] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=16822
COMP: Ensure library paths used for BundleFixup are valid

The helper macro "_fixup_paths_append" is now used consistently to append
path to the "libs_path" variable.

Let's also note the following updates:

 - CMAKE_RUNTIME_OUTPUT_DIRECTORY is not used anymore, instead
${Slicer_BUILD_DIR}/@Slicer_BIN_DIR@ is used.

 - Path "@Slicer_BINARY_DIR@/@Slicer_QtPlugins_DIR@" is not considered
anymore since it didn't exist in the build tree. Instead, the plugin path
are composed using "${Slicer_BUILD_DIR}/@Slicer_BIN_DIR@"
COMP: Do not explicitly fixup CLI shared libraries

Considering that (1) CLI shared lirbary are dependency
of CLI executable and (2) CLI executable are already discovered by the
fixup mechanism. There are no need to use candidate pattern for CLI
shared library.
COMP: Simplify expression used in gp_item_default_embedded_path_override.
STYLE: Easier configuration of fixup path in bundle script
BUG: Ensure library can be loaded from different place using @rpath

Before this commit, attempt have been made (r18311, r18325, r18581) to
install both built-in CLI and extension CLI executable in a folder
located at some depth of the main Slicer executable. This was needed
because all libraries were referenced based on the location of the main
Slicer executable using "@executable_path". This was working *only* in the
case of built-in CLI but wasn't scaling very well for the extension CLI
executable. Indeed, being able to both differentiate the different
installed extension and keeping the depth to 1 level wasn't easily
feasible:

  /path/to/Slicer.app/Contents/MacOS/Slicer
  /path/to/Slicer.app/Contents/cli-modules/MyCLI
  /path/to/Slicer.app/Contents/Extensions-21855/SkullStripper/cli-modules/MyCLI

A solution could have been to install extensions directly in "Slicer.app"
folder and update the cli install sub dir to get something like:

  /path/to/Slicer.app/Extensions-21855/SkullStripper/MyCLI

While possible, it would have remain a special case to maintain.

Instead, by using "@rpath", CLI modules can now be installed in the Slicer
standard location "Slicer_CLIMODULES_LIB_DIR" instead of "Slicer_CLIMODULES_SUBDIR".
This commit remove the special case which never worked (issue #3051)

Waiting the topic "tweak-bundleutilities-for-rpath" is fully matured and
integrated in CMake, use custom version of BundleUtilities and GetPrerequisites.
See http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/tweak-bundleutilities-for-rpath

Since our custom version of the CMake modules now consider "~/usr/.*/lib",
the implementation of "gp_resolved_file_type_override" has been removed.

Remove the hack specific to LibArchive (introduced by commit r19615), since
the library is fixed up using the default library matching pattern, it
will be installed in the expected location.

SlicerExecutionModel has also been updated to skip the installation of
CLI shared library and link the CLI executable with "-rpath" so that it
CLI executable can resolve the location of Slicer libraries.