MONAI inline comments and documentation mistakenly claim loaded volumetric images are of HWD format, but in fact WHD

[MMelQin]

Describe the bug

In many modules of the code base, including the transforms and inferer, inline documentation claims the loaded volumetric images are of the format HWD (channel is added as first index in most cases), e.g. the image_writer which also states using NIfTI dimension of HWD, but this is not correct IMHO, rather, the interpretation should be WHD (or XYZ).

When both model training and validation/inference are using the same library to load images, it does not matter how the docs call the dims, the data is consistently used. When 3rd party software is attempting to provide custom image loader or provide the Tensors, knowing the correct semantically meaning of array index becomes critical.

So this issue in documentation needs to be investigated and addressed.

To Reproduce
Read the documentation of the underlying packages and the MONAI impl, e.g. TK. ITK/SimpleITK image itself may have its internal storage in xyz but array_view_from_image/GetArrayFromImage give ndarray with zyx. MONAI ITKReader _get_array_data then transpose the ndarray to xyz/WHD.

One can run through with data sample below

Steps to reproduce the behavior:

1. Get a XRay DICOM image, modality CR or MG, of unequal Width(Columns) and Height(Rows), and use 3D slicer to load it up and save to nii or nii.gz. CT and MR DCIOM series with equal rows columns may not easily reveal the issue.
2. Load the images with LoadImage, repectively, then examine the ndarray dims and compare them to the DICOM metadata.

Example:
With DICOM image 71300000LCCC-View, PixelData [Rows, columns] (H/Y, W/X): 2457, 1996, single instance and single frame
SITK Image size [Columns, Rows, Depth], size[0], size[1], size[2], same as 3D Slicer: 1996 2457 1
SITK GetArrayFromImage type: <class 'numpy.ndarray'>
SITK nd_array shape, Depth/slices, Height/rows, Width/columns: (1, 2457, 1996), with .T applied, (1996, 2457, 1)

With 71300000LCCC-View.nii.gz
nibabel read img shape: Width/columns, Height/rows, Depth/slices: (1996, 2457, 1)
nibabel get_fdata shape: (1996, 2457, 1)

Expected behavior
Documentation should correctly state the order of dims and the meaning

Environment

Python 3.10.12
monai 1.4.0

Num physical CPUs: 6
Num logical CPUs: 12
Num usable CPUs: 12
CPU usage (%): [29.0, 21.7, 19.3, 26.5, 25.2, 20.0, 25.0, 38.1, 23.6, 25.0, 21.4, 21.9]
CPU freq. (MHz): 1643
Load avg. in last 1, 5, 15 mins (%): [22.4, 21.6, 21.0]
Disk usage (%): 71.3
Avg. sensor temp. (Celsius): UNKNOWN for given OS
Total physical memory (GB): 31.0
Available memory (GB): 11.3
Used memory (GB): 18.5

================================
Printing GPU config...
================================
Num GPUs: 1
Has CUDA: True
CUDA version: 12.4
cuDNN enabled: True
NVIDIA_TF32_OVERRIDE: None
TORCH_ALLOW_TF32_CUBLAS_OVERRIDE: None
cuDNN version: 90100
Current device: 0
Library compiled for CUDA architectures: ['sm_50', 'sm_60', 'sm_70', 'sm_75', 'sm_80', 'sm_86', 'sm_90']
GPU 0 Name: NVIDIA RTX 6000 Ada Generation
GPU 0 Is integrated: False
GPU 0 Is multi GPU board: False
GPU 0 Multi processor count: 142
GPU 0 Total memory (GB): 47.5
GPU 0 CUDA capability (maj.min): 8.9

Additional context
It is noted that there was a issue filed back in 2020, regarding underlying readers' native representation and the numpy array they serve out. This resulted in transposing the ndarray from ITK to get the depth at the correct index, DHW to WHD, but there is no reshape to get to HWD. Hence the doc should say WHD.

It is also noted that the nii file used in the example is created using 3D Slier which loads the original dcm file, and after nibabel loads the nii file, the ndarray shape corresponds to Columns/Width, Rows/Height, and Axial Slice, not the typical (depth, height, width)