New string-based init methods for selections

Necessary to integrate them into macros and undo/reod
Undo handling now requires an Int identifier (instead of Bool)

Integrating selections into undo/redo requires some new handling
techniques.  The undo engine can no longer blindly assume that image
data needs to be backed up to file, because in the case of selections,
we don't care about the image's data - just the selection's data.  So
the Undo engine now requires an integer specifying which type of Undo
data to create.

1 = image data
2 = selection data
Rewrite all Undo/Redo code to support selection data

On its own, this commit won't actually integrate selections into the
Undo/Redo chain - that will come later when all selection actions are
rewritten as PhotoDemon Processes.

But at least the framework is all in place...
Undo/Redo now supports selections

This feature proved to be a bit of a nightmare to implement.  Rather
than rewrite all my Undo/Redo code from scratch, I retrofitted
selections onto my existing Undo/Redo code.  It didn't end up being many
additional LOC, but there were many false starts on the path to a
successful implementation.

At present, Undo/Redo will always make a copy of the current image and
the current selection.  This is wasteful, because an action like moving
a selection will also backup the image, despite no changes being made to
individual pixels.  The present Undo/Redo infrastructure doesn't provide
a good way to assess whether an Undo action is selection-based or
pixel-based, despite many attempts to make such a thing work, but I will
revisit this in the future.

As this feature required changes to a number of deeply integrated code
modules, additional testing will be necessary.