Undo/Redo engine overhaul

(I have wanted to do this for a very, very long time.)

PD has had Undo/Redo support since pretty much its inception.  The first
incarnation stored a byte array of the prior image state in memory,
which allowed for a single undo operation to be performed.  Over time,
the Undo system has grown much more complex, but it has done so by
strapping ever more features onto that original flimsy framework.

Fast-forward to 2013, and PD's Undo/Redo code was a hot mess, with
functionality split across various modules and classes, with a bunch of
tangled functions repeating the same behaviors at each step of the
process, but not in a predictable way.

Thus the need for a rewrite.  As of this commit, all Undo/Redo data is
now encapsulated within a single pdUndo class.  Each pdImage object
contains one instance of pdUndo.  ALL Undo/Redo functionality is handled
through this class, specifically via something like
pdImages(imageIndex).undoManager.whatever.

This should make it significantly easier to debug Undo/Redo stuff in the
future, as well as expand its capabilities to include things like a full
history browser.

Some interface code remains in the pdUndo class for now.  I will be
removing this shortly, but it requires the creation of a new (and
much-improved) function for synchronizing the interface to the image's
current state.  Stay tuned.
Large interface/domain code overhaul

In a complex program like PD, keeping the interface in sync with
background data is *hard*.  Not only do the various photo editing
actions interact in complex ways, but all data has to be maintained for
multiple open images, including complex datasets like Undo/Redo chains
or live selections with a dozen unique properties.

As PD has gained more and more features, the responsibility for handling
proper dis/enabling of controls has fallen to individual functions.
This has led to literally hundreds of separate pieces of management code
throughout the program, all of which act independent of other actions,
and the interactions of which sometimes produce unexpected results.

But no more!  I have completely reworked the way PD handles
domain/interface interaction, and the new approach is significantly
faster, simpler, and less error-prone.

A new syncInterfaceToCurrentImage function lies at the heart of the new
system.  This function can be called at any time, and it will
automatically dis/enable every menu, button, and other control in the
program to match the currently active image.  Individual functions no
longer need to care about what menu items they affect - they simply need
call this function, and all interface elements will be updated to match.

Similarly, any call to the central Process function will now
automatically refresh the interface to match any changes resulting from
that process.  This centralized approach is far preferable to the old
piecemeal nonsense, and if changes need to be made to interface
handling, they now only need to be made to a single function.

The pdImage class still exposes more public variables than I would like,
and in the future I will be moving those to get/set functions.  But for
now at least, the number of functions that access those public variables
have been *greatly* reduced.

In line with this change, all interface code has been purged from a
number of functions, including a full purge from the Undo class.  This
has not only shrunk PD's codebase by a nontrivial amount, but it has
also resulted in much better encapsulation throughout the project.

I'm hoping this change also fixes a number of long-standing and very
difficult-to-reproduce relating to menu items inexplicably being
en/disabled when they shouldn't be.
Improve comments
Check for thunks before removing from subclasser collection

A "remove thunk from collection" line was throwing errors at me, so I
implemented a basic check to see if a thunk exists before removing it
from a collection.  That seemed to solve the problem.

Chances are that I'm attempting to unsubclass something I never
subclassed in the first place - will investigate, but as I see no harm
in this fix (and in fact, it makes the class more robust), I think I'll
leave it.
Start work on a new Theming class

From issue #89: "PD's default theme is very bright. This is not always
ideal when working with images, as you generally want darker, less
distracting chrome to give you a better feel for how the image itself
appears."

The long-term goal is to implement actual user-selectable visual themes,
with an emphasis on at least two: "current Windows theme" and "darkroom
theme".  Applying said themes will be worked into the makeFormPretty
function, which already handles control enumeration for every form in
the project.

Anyway, this new class doesn't do anything theme-related just yet, but I
needed a class for handling IDE-safe subclassing of container controls
(in order to render them with transparent backgrounds).  So I thought
I'd get a jump-start on theming and just create a dedicated class for
it.

(This commit also includes the new safe subclassing code.)