Transposition logic finished, tested.

Finished implementation of transposition logic.  Brief implementation
description: Static_MIDI_Event (whose [class] name will probably change to
something like Regular_MIDI_Event) subscribes to status changes with
respect to transposition (e.g., the user hits a pedal/key combination that,
according to the configuration, indicates that a configured note range is
to be transposed by a configured number of half steps - if the user hits
this combo for the first time, transpositions for that range are enabled;
if she/he hits it again, transpositions are disabled, etc.).  The status
change is indicated by calling the toggle_transposition method on the
subscriber (i.e., Static_MIDI_Event), which, for the specified note range
(according to the configuration) modifies a hash table (with the pitch
values of the note range as keys) to indicate that transposition for that
range is turned on if it was off before and vice versa.  When a note event
for a note in one of the transposition ranges is received, if
a transposition is currently enabled for that pitch, the value for that
transposition is obtained (number of half steps [i.e., an integer with
respect to MIDI pitches], which can be positive [transpose up] or negative
[down]) and added to the current pitch before the current MIDI event (with
the modified pitch value) is output to the configured MIDI clients.

Question:  What will happen if overlapping transpositions for a particular
pitch are configured and invoked?  If all enabled transpositions are
applied, that is, perhaps, acceptable.  But if this causes a true
malfunction of the process - either by causing incorrect behavior or a core
dump -, this should be considered a bug.