polymorphic pixel type reader

When using an ITK reader one needs to specify a pixel type, but many file formats, including DICOM, are polymorphic and the actual data type is only known by reading the file.

Slicer includes a layer that queries the data type and then uses macros so that the native data type of the file can be returned. This is all implemented in the VTK code that wraps ITK, such as these examples:

https://github.com/Slicer/Slicer/blob/master/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L190

https://github.com/Slicer/Slicer/blob/dac2a3d60e91aeee5912751509455be2217f69fd/Libs/vtkITK/vtkITKArchetypeImageSeriesScalarReader.cxx#L90

It would be great if ITK implemented a more native support for this pattern to simplify the logic for users of the code.

This was discussed as an issue on the Slicer forum topic here:

https://discourse.slicer.org/t/slicer-dicom-scalar-volume-plugin-relies-on-old-gdcm-why-do-we-not-use-dcmtk/354/11

Review the Slicer examples in vtkITKArchetypeImageSeriesReader.cxx and vtkITKArchetypeImageSeriesScalarReader.cxx, then compare their approach with the ITKDICOM reader interfaces. Determine how native polymorphic pixel-type support should fit into ITK and validate the design against the DICOM use case and linked forum discussion.

Written by the indexing model from the issue text.