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.