Redesign central processor

Warning: huge commit!

A core tenet of PhotoDemon's design philosophy is its reliance on a
central "software processor".  Almost every operation in the program is
passed through a global function called "Process", and this function
examines each process request, then performs a host of support
operations contingent on the type of operation.

For example, if it gets a "Blur" request, it knows to create an Undo
file, change the screen cursor to "busy", disable the main form, prepare
the progress bar, and when the operation is finished, return everything
to normal.

This software processor concept was necessary to support macro
recording, as I needed a way to record every action the program takes,
then play those actions back at a later date.

Unfortunately, the software processor's design is a decade old at this
point, and a number of poor original decisions have made it very
difficult to add new features and improve existing ones.  Among the
worst was a decision to hard-code ten possible process parameters of
Variant type, which calling functions could use to specify things like
"blur radius" or "use bilinear resampling".

At the time, 10 parameters seemed like plenty, but as PhotoDemon has
grown more complex, the need for a more flexible parameter scheme has
become very clear.  For example, I have been unable to add a Curves
dialog, despite having Curves code written for many years, because
PhotoDemon's central processor couldn't handle enough parameters to
record the many data points generated by Curve actions.

BUT!  As of this commit, everything has changed.  I have completely
rebuilt the software processor to rely upon a single string parameter,
and I've added a host of support functions to simplify this new method
across the program.  A new "buildParams" function can be used to
concatenate any type and number of parameters into a single
"|"-delimited string, and a specialized pdParams class now exists to
parse those parameters out into specifically typed variables within the
processor (instead of the Variant mess used before).

This should effectively future-proof the program against any future
feature additions.

Because this change required me to rewrite hundreds of process calls
throughout the program, I used the opportunity to implement another
change I've long wanted to make: string-based process IDs.

Previously, each possible action in PD was assigned a numeric
identifier.  This seemed like a good idea back when there were 15-20
possible operations, but it has become increasingly unwieldy as the
number of effects and filters has grown.  Attempts to sort these numeric
identifiers into groups was also pointless, and the use of hard-coded
constants made it very difficult to retroactively organize or sort the
IDs, as any ID changes broke existing macros.  This required an
increasing complex translation system to provide backwards
compatibility, and both performance and code clarity suffered as a
result.

But no more!  Process IDs have been converted to human-readable strings,
like "Open" or "Count image colors".  The use of strings not only makes
the code much more readable - it will also make macro recording and
editing MUCH simpler, as I won't have to constantly translate between
numeric and string IDs for all interface elements.  This will also
facilitate a planned move to XML-format files for macros, and it's a key
component of a planned "filter browser" that allows the user to preview
all tools and effects in a single dialog.

Anyway, because of the scope of the change (72 files being committed), I
can't be certain that nothing broke.  I have manually tested every
action and menu item that gets routed through the processor, and I've
also implemented a function that should be able to convert over 95+% of
macros that use the old numeric system.  (When loaded, the macros will
be translated into the new format, then saved back out to file.)  All
macros I have recorded, which include many but not ALL program
functions, are successfully updated by my code.  Some obscure functions
cannot be supported, but I'm hoping no one utilized them in a macro...

Batch convert + macros also works, and I believe all language
translation features still work as well.

(As a nice bonus, this change reduced .exe size by a pleasant amount.)