Do not use fast path when image type is floating point

This might change in the future since DICOM is adding floating point data. We'll see how it goes
Handle special case where shift/scale is 0/1

In some case user would try to store a floating point value with special values of shift/scale. vtkGDCMImageReader was relying on those special values to compute a fast path. This is wrong when image type is floating point.
Add a simple example which shows how to create a fake RTDOSE file
Make sure user cannot use Intercept value
Handle case where user wants signed PNM
In some case PNM files were not really big endian, add a way to force that