ENH: Subject hierarchy module added

This is the first step of integrating Subject hierarchy into Slicer core. Next steps include moving subject hierarchy plugins to their related modules and making DICOM import plugins add loaded objects in the hierarchy.
More information: http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/SubjectHierarchy
ENH: Node attribute table view and widget moved to MRMLWidgets

Now both Data and Subject hierarchy modules use qMRMLNodeAttributeTableView and qMRMLNodeAttributeTableWidget, so they have been moved from Data module widgets to MRMLWidgets
ENH: Moved core module subject hierarchy plugins to related module

Subject hierarchy plugins project contained plugins for core modules Markups, Models and Volumes. Those plugins are now in the SubjectHierarchyPlugins subdirectory of those loadable modules.
Also the subject hierarchy support moved from SlicerRT/DicomRtImport/DicomRtImportPlugin.py to DICOMScalarVolumePlugin.py. Now the loaded DICOM scalar volumes are automatically added to subject hierarchy.
ENH: Sank addSeriesInSubjectHierarchy function down to abstract DICOMPlugin

The addSeriesInSubjectHierarchy function (which was in DICOMScalarVolumePlugin so far) adds the loaded node to subject hierarchy to the proper patient (subject) and study according to the DICOM tags from the first file referenced in the associated loadable. This function is now accessible from all the DICOM plugins. It needs to be called after the loaded object is created in the load() function. Now it is called by DICOMDiffusionVolumePlugin too.
ENH: vtkMRMLHierarchyNode methods made virtual

Two methods in vtkMRMLHierarchyNode made virtual. GetAssociatedChildrendNodes contained a typo so it is now called GetAssociatedChildrenNodes. Subject hierarchy volumes plugin now can add volumes from potential list to tree
ENH: MRMLCLI_INCLUDE_DIRS CMake variable exported

It is needed for some subject hierarchy plugins to include the MRMLCLI indlude directories, and by exporting this variable it is possible to do it without manually constructing the paths in the CMakeLists files
ENH: Subject hierarchy python tests moved to SlicerApp

As the subject hierarchy tests cover multiple modules, they have been moved from the SubjectHierarchy folder to Applications/SlicerApp/Testing/Python; Occasional SlicerRT strings removed/replaced in subject hierarchy code (mostly include dir comments)
COMP: Moved subject hierarchy base plugin classes in widgets

In order to subject hierarchy plugins be accessible from extensions, the include directories need to be exported. So that the current infrastructure can be used, all subject hierarchy plugin classes (abstract, handler, core plugins not related to modules) were moved from Plugins to Widgets. Plugins subdirectory thus became unnecessary and removed.
COMP: Fixed Mac and Linux build error

Subject hierarchy widget designer plugins were deployed to Slicer_DIR/bin, which broke the Linux and Mac build. This explicit output directory setting has been removed.
BUG: Fixed subject hierarchy core plugins self test

Which failed due to renaming of GetAssociatedDataNode to GetAssociatedNode in vtkMRMLSubjectHierarchyNode. It has been renamed, because by making vtkMRMLHierarchyNode::GetAssociatedNode virtual, it became possible to override it in subject hierarchy so that it can handle nested associations.