Improved approach to high bit-depth images

A lot of dSLRs will write RAW files without embedded ICC profiles.  This
leaves us no choice but to estimate 24bpp conversion using a
tone-mapping operator.

In the rare event that we encounter a high bit-depth image with an
embedded ICC profile, however, PD will now preferentially use the ICC
profile for the transformation.

The current mechanism isn't ideal, because the high bit-depth copy will
be forcibly converted to 24bpp *prior* to applying the ICC profile.  A
better mechanism would be to do the 24bpp conversion directly from 48bpp
(or 96bpp), using the ICC profile.  I can't easily do this at present
because I don't have a good container for high bit-depth images, so in
the meantime, the current approach will have to do.

(For what it's worth, the current approach provides perceptually
identical results to Windows Photo Viewer and GIMP, and much better
results than Paint.NET, so I consider it acceptable.)
Custom check box: smarter painting approach

I'm still having issues with flickering under Aero, but it's extremely
unpredictable - aaarrrggghhh.

One possible cause is that I'm naively recreating the back buffer on
paint events, which is both dumb and unnecessary.  The control already
maintains a detailed notion of when it needs to be recreated vs when it
simply needs to be flipped to the screen, so with a few small changes,
I've greatly improved the overall painting approach.  Among other
things, this makes the control much more lightweight, as paint messages
will now result in a single BitBlt and Validation, rather than forcibly
recreating the backbuffer.

For now, this seems to solve flickering, but given the problem's
unpredictability, I may have no choice but to revisit again in the
future.