Fix DPX handling of unsupported pixel data types

The general rule is that if a file type doesn't support the data type
requested, it silently substitutes a supported data type (usually one
that loses as little precision or range as possible).

DPX somehow lacked this logic, and we didn't notice until recently. In
particular, something like

    oiiotool in.dpx -d half -o out.dpx

Would result in garbage in the pixel, since it was not properly
converting types or substituting one actually supported by DPX.

The true supported types of DPX are uint8, uint16 (including 10 and 12
bit variants), float, and double. Now half will be output as float, and
all other unsupported types will be output as uint16.