Convert tons of functions to layer-friendly wrappers

Many, many PD functions currently access an image's main layer directly.
In order to implement layers, this behavior needs to stop, because the
concept of a "main layer" will soon disappear.

Instead, functions need to either access an image's active layer (via
.getActiveLayer()) or the fully composited image (via
.getCompositedImage()).  This commit attempts to replace .mainLayer
references with these functions when possible.

Certain functions, primarily the Image menu, need to iterate through all
layers in an image and modify them all in turn.  I don't have a
framework for this yet, and won't until I actually implement layer
storage as an array of layers.  Once that happens, all Image menu items
will need to be completely rewritten.  (Not looking forward to that.)
Use pre-multiplied alpha by default

(Relates to #96)

This may not seem like much of a change, but it's actually a ground-up
rewrite of the way PD handles 32bpp data.  Premultiplied alpha is
required for hardware-accelerated transparent rendering (via
AlphaBlend), and with layers support coming, it was impractical to
continue doing my own manual compositing.

This commit primarily affects the handling of premultiplied data at
load-time.  Much more work is required to fix the additional
implications throughout the software.
Rewrite alpha checkerboard rendering system

Previously, temporary copies of 32bpp images self-composited against a
checkerboard background on-demand (typically just before rendering to
the screen).  This required the use of custom pre-multiplication code
that had to be re-applied every time an on-screen copy of a 32bpp image
was updated.

Now, we simply cache a 2x2 grid of the current alpha pattern, and render
it on-demand using PatBlt, then overlay the 32bpp data using AlphaBlend.
This provides much better (faster) results.
Rewrite image tool pre- and post-processors to work with new alpha code

(Relates to #96)

For the record, this commit also includes a number of high-level changes
to the pre/post-processors to make the eventual addition of pan/zoom
previewing possible.

While pre-multiplied alpha is great for improving performance of
on-screen rendering, it must be removed prior to editing image data.
Otherwise, the RGB data will be incorrect and simple actions like
"brighten" will return faulty data (because the RGB data includes alpha
data from the premultiplication).

So for 32bpp data, the pre-processor now removes premultiplication,
while the post-processor adds it back in.

I have also completely rewritten the way selected regions are handled.
When a selection is active, the full selected rect - without
modification - is sent to the image tool, even during previewing.  When
the tool completes, the post-processor now performs a full composite of
the selected area, then renders that to the preview area.

Previously, only the selected area was displayed, but now, the user can
see how the selected area will composite against the final image, which
I think is much more helpful, particularly when working with feathered
selections.

A number of changes were also made to the fxPreview user control to
handle this new data correctly.
Fix 32bpp handling in the Unsaved Changes dialog

(Relates to #96)

As the renderToPicture box function is now capable of doing its own
32bpp compositing, there is no need to do it manually in the unsaved
changes dialog.  Less code + better result = happy Tanner.
Fix batch wizard previewing to account for premultiplied alpha

(Relates to #96)

Again, it used to be necessary to specially handle the previewing of
32bpp data, but that is no longer the case due to the premultiplication
rewrite.
Remove premultiplication prior to saving

(Relates to #96)

Obviously, premultiplication is not appropriate for saved images.  Prior
to saving, the master save function automatically un-premultiplies 32bpp
images.  When the save is complete (or canceled), premultiplication is
re-applied.
Remove manual premultiplication from thumbnail bar

So nice to be able to do this - and it greatly improves performance as
well, particularly when resizing a full thumbnail bar!