Undo/Redo engine: diff-based overhaul complete

Hallelujah.

With this commit, PD's Undo/Redo engine can now diff standalone image
headers, which is a lifesaver for program responsiveness while
reordering the layer stack.  This proved to be the messiest specialized
diff handler of all, as we have to non-destructively rebuild the
existing layer stack to match stack information previously written out
to file, while still catering to all the usual nonsense of
considerations like separate layer and layer header diff points
depending on the user's workflow.

I seriously doubt I will ever be able to make sense of this code again,
although I have tried my hardest to comment everything extensively.  The
complex interactions involved have made this one of the toughest PD
projects in recent memory, but I believe the Undo/Redo engine is now as
future-proof as I can reasonably make it.  (With paint tools and many
new layer features in the pipeline, future-proofing was a big point of
this rewrite.)

While I think it's fair to consider the current implementation
"best-in-class" among free photo editors, there is still room for
improvement.  A few ideas for the future:

- I still need to capture layer opacity and blend mode changes; these
are not currently handled by the Undo/Redo engine, as they don't pass
through the central processor.

- Non-destructive changes (like moving layers around, or toggling their
blend modes) should be marked as such, so that the Undo engine knows to
merge such actions into a single point if they occur sequentially.

- For operations that can be easily reversed via existing code (e.g.
"Invert RGB", "Flip horizontally", etc), it would be nice to handle
their Undo/Redo-ing via code.  This would allow us to completely skip
Undo file creation for such actions.

- Planned updates and optimizations to the pdPackage interface (used to
write PDI files and all specialized Undo files) will have trickle
effects on Undo/Redo creation.  I plan to offer a new "Performance"
category of preferences for items like this, where the user can choose
to enable things like compression of Undo data.  This imposes a
performance penalty, but obviously saves on file space.  (There are a
number of places in PD where performance trade-offs like this would be
beneficial, so I think it makes sense to supply them as preferences.)