Make DICOMSeriesToVolumeOperator consistent with ITK in serving NumPy array

[MMelQin]

The noted issue in the generated DICOM Seg instance will be investigated outside of this PR.

The Image object instances in the application pipeline was not completely consistent in its representation of the pixel in NumPy array, especial around the index order, i.e. DWH or DHW. One wonders if the representation is similar to what's provided in other packages, e.g. (Simple) ITK.

This PR intends to make the App SDK Image object instances in the processing pipeline of an application more consistent by separating the concerns during image loading of DICOM instance, during inference using MONAI transforms including re-shaping the image array, and the output Image after inference:

1. Consistent with ITK on converting DICOM series instances to volumetric image in DICOMSeriesToVolumeOperator. The NumPy array of the App SDK Image instance has array index order of DHW, and the metadata for pixel spacing and orientation have save values as loaded by (Simple) ITK. This image object is used by downstream operators, e.g. ClaraViz operator, segmentation operator, etc.
2. Consistent with MONAI ITKReader on serving out pixel data and metadata in the InMemImageReader, used in the SegmentationInferenceOperator. MONAI has multiple ImageReader implementations, each for loading certain file formats, and ITKReader is for DICOM instances. To have consistent data representation (with NibabelReader), ITKReader rearranges the NumPy array internally before severing out data, see the implementation in monai 0.7. The InMemImageReader is then made consistent with ITKReader.
3. The Image object encapsulating the segmentation inference results is consistent with that of ITK, e.g. the data NumPy array index order is DHW. This Seg image is used by ClaraViz integration operator, the new STL mesh operator, as well as the DICOMSegmentationWriterOperator.

Code changes have been tested:

• The Image loaded from DICOM is as expected.
• The MONAI inference pipeline in the Segmentation Operator works fine with the updated InMemImageReader, and generates the segmentation image in NIfTI same as before.
• The DICOM Segmentation writer, with the in-mem Image object as input, generates DICOM Seg instance which has multiple segment slices in the same frame. This is an issue, and is still being worked on. Even with the NIfTI image file generated in the inference pipeline, the DICOM Segmentation writer also generates the same (bad) DICOM Seg instance. It is also noted that the DICOMSegmentationWriterOperator itself did not change.

Update:
The aforementioned DICOMSegmentationWriterOperator issures have been reproduced in App SDK main, tag 0.1.1, and 0.2, so the changes within this PR are not the cause of the errors. It is further noted that the DICOMSegmentationWriterOperator had been tested working properly in release v0.2, except a known issue with a specific input data set. It is unknown what the root cause is as of now, and plan to investigate and fix the root cause outside of this PR.