First step to addressing broken accelerators (#38)

This commit adds a number of new features to the way custom accelerators
(hotkeys) are tracked and processed.  There are two main goals here:

1) To replace all existing VB-based menu accelerators (haven't touched
this yet)
2) To automate as much of the accelerator process as possible (that's
what this commit does)

Theoretically, every menu in PD is simply a trigger for a Processor
module action.  By dynamically associating a hotkey with a menu, we
should be able to automate the hotkey process by simply launching
whatever processor string is associated with that menu.

I have now reworked the accelerator handler to work like this, and I
have transferred all existing custom accelerators to the new system (the
ones that tie into software processor actions, anyway - some still do
not, so they require the old custom handling code).  Starting tomorrow,
I will start removing VB-based menu accelerators and moving them to this
custom system.

The immediate benefit of this is that accelerators will no longer
require particular forms to have focus in order to work.

The long-term benefit of this is that it will be much easier to
implement a user-editable system for hotkeys.  It will also be
significantly easier for me to add hotkeys to menu items, so perhaps I
can even build a good collection of hotkeys before 6.0 releases.  (Right
now, PD's hotkey selection is a hodgepodge mess.)