BUG: Fixed scene views with subject hierarchy 2.0

Some explanation besides the subject hierarchy node and scene view node changes:

1. vtkMRMLScene.cxx:1140 and 1175:
   1/A) the ReferencedIDChanges map contained an invalid entry in every case, namely it associated the last created node's ID with empty string.
   1/B) In the case of loading a volume, the test scene created by vtkSlicerVolumesLogic::AddArchetypeVolume assigned ID with number 1 to the volume. Then, when adding it to the main MRML scene, the old ID with number 1 was found, and the ID change was stored always from 1 to the number of the last loaded volume. This is also an invalid ID change, as no ID was changed in the scene that stored this change. First approach was to clear node ID when removing from scene, but it caused tests failing in EMSegment (due to the specific way it creates sub-scenes), and it is expected to cause problems elsewhere too. So as an alternative solution, IDs are only added to ReferencedIDChanges, when a scene is being imported or a scene view restored. It seems to be reasonable, as these are the only two use cases where the IDs of other complete scenes need to be merged to the main Slicer scene.
2. vtkMRMLSegmentationNode.cxx: This is basically reverting commit rev25625 that introduced display node copying and creation in the data node's copy. In the case of restoring the scene view, it caused a problem like this: if the segmentation node was before its display node in the snapshot scene, a new display node was created when copying the segmentation node, and so after restoring, two display nodes were present instead of one. So the segmentation was not visible. I checked other data nodes and none of the ones I looked at copy display properties in the copy function of the data node. I suggest taking care of this at the higher level, where the data node's copy is called (for example as it is done in the clone node SH plugin)

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