Undo/Redo: track relevant layer ID (if any)

Actions that affect only a single layer need to note the affected
layer's ID; this will allow us to calculate diffs for that layer only
when Undo/Redo is used.
Undo/Redo: new dedicated Save functions for Undo data and single pdLayer objects

This allows us to save/retrieve a single layer at once, a key part of
the new Undo/Redo engine.

Also, this commit includes a slight tweak to PD's PDI file format (one
that doesn't affect existing PDI files, thankfully).  Layers in a PDI
file now have their unique layer ID's stored as the node ID's in the
file; this will allow us to extract individual layers more easily,
regardless of their order.
Undo/Redo: diffs now implemented for single-layer actions

Oh man, this is giving me a headache.  I have a whole new appreciation
for Git after trying to implement my own diff-based engine.

Headache aside, PD's Undo/Redo engine should now be capable of
"diff-ing" actions that only affect a single layer.  Said another way,
any program action that modifies just one layer (e.g. anything in the
Adjustment or Effects menu) will result in an Undo file consisting of
*just the changes to that layer*.  This makes nearly all program
operations faster, because instead of saving the full pdImage stack to
file, we will only save the changes to a given layer.  The total size
required by PD's Undo files is also much, much smaller when working with
multi-layer images.

As expected, a diff-based approach causes some unpleasant interactions
when the user clicks Undo.  Consider the following chain of events:

1) Load PDI file with 10 layers
2) Apply some modification to Layer #5
3) Apply some modification to Layer #7
4) Flatten the image

Step 4 results in a completely modified pdImage object (e.g. only 1
layer instead of 10), so if the user chooses to Undo it, the diff engine
must scan the Undo stack for the most recent copy of the full pdImage
object (because we need to recreate all ten layers from scratch).  The
nearest valid pdImage object entry is at the base of the Undo stack,
specifically the Undo file created when the image was first loaded.  The
diff engine thus uses that snapshot to reconstruct the pdImage stack
with all ten layers.

But wait!  That base Undo entry contains a copy of all layers *as they
appeared at that point in time*.  For Layers #5 and #7, that snapshot
won't include any of the subsequent changes applied by the user!

What does this mean?  The diff engine must now process each individual
layer, looking for subsequent diffs that might have modified that layer.
When they are found, they are re-applied to the given layer, until
finally we have recreated the image as it appeared immediately prior to
the user flattening it.

I have tried to optimize this process as much as humanly possible, and I
think Undo/Redo actions remain quite snappy, all things considered.
Unchanged layers are processed very rapidly, as the diff engine detects
that their most recent valid data occurs at the same point as the full
pdImage stack Undo entry, so such layers do not receive any additional
processing.

Still left to receive custom handling are image header and layer header
changes.  Special handling for these will allow us to minimize the
amount of Undo churn for things like moving a layer (which only affects
two Long-type values in the layer header, and thus shouldn't result in a
copy of layer bitmap data).

Additional testing is most welcome to make sure I haven't overlooked any
edge cases for this rather complicated program behavior.