ENH: Improved Crop Volume module

While assisting many users in learning segmenting using Segment Editor, it turned out that Crop Volume module is an essential pre-processing tool for segmentation. Either for reducing size of large volumes (cropping/downsampling) or allowing better segmentation of structures that are comparable to the voxel size (cropping/upsampling).

Crop Volume had many limitations, all of them fixed in this pull request:

• Cropping of transformed or non-axis aligned volumes and ROIs was very limited (input volume was not allowed to be transformed, non-linear transforms were not allowed) - now interpolated cropping allows linear transforms of any volumes or ROIs, input volume can even be non-linearly transformed
• No output volume was selectable (this was unlike all other modules in Slicer and it often lead to creating several unneeded output volumes when experimenting with cropping parameters) => now output volume can be specified (if not specified then it is created automatically)
• If inconsistency was found (e.g., misaligned ROI and input volume for voxel-based cropping) then a popup was displayed and users' node selections were reverted, which often disrupted user's workflow (for example, it was not possible to switch input volume and then switch to corresponding ROI because after switching input volume there was a temporary inconsistency that the module wanted to resolve immediately) => now when there is any inconsistency, an error message is displayed and Apply button is disabled; the user can either resolve inconsistencies by selecting different nodes, changing transforms, or clicking the Fix button to automatically resolve all inconsistencies by changing/aligning transforms
• It was tedious to initialize ROI to include the entire volume (e.g., when the goal was to decrease resolution or crop only on one side) => now a ROI auto-fit button is available
• Meaning of "Input spacing scaling constant" parameter was not clear (is it an absolute spacing value or a factor relative to current spacing; what value increases/decreases the resolution) and it was often difficult to predict how large the cropped output volume will be without actually performing the cropping. => now in the Volume information section users can immediately see what the size and resolution of the cropped volume will be
• Cropping of large volumes required lots of memory (voxel-based cropping created extra unnecessary temporary vtkImageData objects; interpolated cropping created an unnecessary reference volume, instead of just specifying output volume geometry using CLI arguments) => no unnecessary images are created now
• Spacing was not computed correctly for volumes where the order of axes were permuted (for example in MRHead sample) => axes between input and output volumes are now correctly matched