Enhance ImageBuf iterator logic to fix subtle resize problem.

The ImageBuf iterators implement wrap modes, but were a little squirrely
about how they should behave with overscanned images.  (We define "NDC"
or 0-1 space as the 'display/full window', but were wrapping based on
the pixel data window.)

Separately from that, we noticed a resize problem for certain cropped
images that resulted from our practice of clipping the filter kernel at
the edge of the data window (itself a heuristic aimed at preventing
creeping black at the edge of resized images that would resulting from the
part of the filter kernel that hangs off the edge of the data window --
in particular, if you make a MIPmap of a source image with solid 1.0 alpha,
you expect it to be solid 1.0 on all the levels, right up to the edge).
Yet this filter clipping was biting us in the butt for cases where the
input image was cropped. It's hard to explain in ASCII, but it led to weird
artifacts at the edges.

Long story short, this patch cleans up both of these problems as follows:

1. Make the IB::Iterator logic more robust, truly wrap using the
full/display window as the boundary, but also let overscan take
precedence when those extra over-the-edge pixels are available.

2. Simplify the resize logic to no longer clip the filter kernel or skip
parts "off the edge." Instead we rely on the Iterator behavior and
instruct it to use "clamp" wrap mode at the edge of the display (not
data!)  window.
Fix OpenEXR write_scanlines handling of per-channel data types.
Subtle problem that could scramble the buffer.

Also, make 'oiiotool -d' a little less likely to have a latent but
for particular unusual channel orders, when sorting out the -d arguments.