MIDI_Event table optimization: hash[string] -> hash[int]

Optimization: Changed "event table" used to hold the MIDI_Event (subclass)
objects for quick access before invoking the correct object's "dispatch"
routine ($event->dispatch($self)).  The old version used a hash reference
(whose attribute name was _midi_event_map) with the state-transition name
(e.g., "$oldstate->$newstate" [e.g., 'NORMAL->OVERRIDE']) as the key to the
correct object (with correct MIDI_Event subclass) for the appropriate
dispatching of the currently received ('input') event.  The new version
uses an array reference (whose attribute name is _midi_event_table) with an
integer state-transition value as the key. This value is the sum of two values:
the "from-state" value for the old state plus the "to-state" value for the
new state.  (See the line:
    $old_state + $to_state_value->[$new_state];
at the end of 'execute_state_change'.)  See MIDI_Facilities for the new
constant definitions, with some explanatory comments, used for this new
integer-based state-transition logic.

Ran some performance tests on the old (hash-based) and new (array-based)
version, using Devel::NYTProf and ardour with a pre-recorded MIDI sequence
for "duplicatibility" [with two different data sets (the 2nd set with two
tracks in which the 2nd track was loaded with MIDI events to cause many
different state transitions in the midifilter process) - a couple runs
each].  The results showed a slight improvement in the new array-based
version, but the improvement is probably not enough to be significant.
Despite the improvement being small, I will probably keep this new version
because the design is reasonable (slightly, perhaps, more complex than the
original version) and because if new states/transition-types are added
(i.e., if the [MIDI_Event] "event table" becomes larger), the performance
benefit over the old version may increase.  The new config3 configuration
file was used for the performance tests.

Also, a bug fix and a small improvement or two:  Bug fix: In
FilterSpecification, the 'realtime_*' attributes were uninitialized if
there are no realtime settings in the configuration file, which causes a
"Use of uninitialized value..." warning.  The fix is to initialize them
(via 'default => sub {-1}') to -1.  NOTE: There may be other
configuration-related attributes with no 'default' setting for which this
bug may also be present.  Improvement: use a 'state $DEBUG' constant
variable (defined in MIDI_Facilities) to speed up the process of querying
whether debug status is true (as opposed to calling the 'debug' routine in
MIDI_Configuration).  Improvement: Moved $valid_state_transitions from
MIDI_StateMachine to MIDI_Facilities.

Finally, for the optimization tests, I moved the call to
'execute_state_change' and the retrieval of the correct MIDI_Event from
_midi_event_table into its own routine to make it easier to read and
analyze the NYTProf tests results.  This will have to be undone because the
extra subroutine call adds a small performance overhead.
defaults in FilterSpecification; and remove 'next_event'.

FilterSpecification: Bug fix: Added a 'default' setting for several
attributes (which didn't have this setting) to avoid "Use of uninitialized
value..." warnings when a setting represented by an attribute is not
configured.  (The realtime_* attributes were fixed in this way in the
last revision.)

MIDI_StateMachine: Undid the moving of state-transition/next-event logic
into a 'next_event' routine (i.e., moved the logic back into
'dispatch_next_event').  'next_event' was created for easier profiling
with NYTProf and is now no longer needed; elimination of the subroutine
call will speed things up a tiny bit.