Signed-off-by: Christopher Arndt <chris@chrisarndt.de>

UI scaling was previously accidentally committed in
63259bf

This is reformatted patch from @johnfolk, who describes it:

The 'problem' was that the MIDI note range always was starting from the
non-transposed left edge (24 or max (left, 36)) to the non-transposed split
point. If there were unused keys to the left (i.e. less than 24 or 36)
they were not used even if they might map to B3 keys and were above 'left'.
The last region had the same issue but the code was somewhat different before
leading to somewhat different effects but the casuse was similar, the unused
note numbers on the left edge.

The strategy now is to use all possible MIDI note numbers by adjusting the
`first_MIDI_Note` and transpose to maintain the difference between them but
move the first MIDI lower as much as possible. Thereby extending the range
of note numbers that would be attmpted to match the B3's range. Then adjust
if needed the start MIDI and key to match the left boundary from the previous
split point (as before). The main thing is to be sure that the mapping constant:

  `offset = trnp + firstkey - first_MIDI_Note`

has not changed and that we respect the left limit on first_MIDI_Note. While
increasing the range to the left to include any unused MIDI note numbers that
would map to valid keys.

This works correctly for a reasonble range of
`m->transpose + m->nshA_PL, m->splitA_PL`. Note numbers will stay >= 0.
If transposes get wild they simply will not map to any keys. At the end of the
day the Midi+transpose must hit the limited key ranges or the table seems to
get set to 255. Which is fine.

Add a config file containing the CC mappings which are compatible with
setBfree's existing control functions. Some features do not map
precisely to how setBfree interprets the control codes, for example the
Rotary controls - support for this will be implemented in a subsequent
commit.

NB. this is experimental for devs (future use) only. By default
setBfree should not be compiled with b_conv, which was somewhat
a failed attempt at modeling horn speaker and cabinet
characteristics.

Previously all assignments were using the upper manual's channel
assignment regardless of the channel-mapping

This fixes an issue on some systems where the DSP can emit more
messages than the UI can consume in a given time.

Also modern forge.h (1.16.0) does not correctly protect against overflow.
----
#0  0x00005555555838f2 in lv2_atom_forge_raw (forge=0x555555b72a10, data=0x7fffe415a9c0, size=8) at /usr/lib/lv2/atom.lv2/forge.h:292
#1  0x000055555558399f in lv2_atom_forge_write (forge=0x555555b72a10, data=0x7fffe415a9c0, size=8) at /usr/lib/lv2/atom.lv2/forge.h:310
#2  0x0000555555583d65 in lv2_atom_forge_property_head (forge=0x555555b72a10, key=16, context=0) at /usr/lib/lv2/atom.lv2/forge.h:636
#3  0x000055555558434a in forge_kvcontrolmessage (forge=0x555555b72a10, uris=0x555555b72ad0, key=0x5555555a8964 "vibrato.lower", value=0) at ../b_synth/uris.h:169
#4  0x0000555555584c23 in mctl_cb (fnid=34, fn=0x5555555a8964 "vibrato.lower", val=0 '\000', mm=0x0, arg=0x555555b72a10) at ../b_synth/lv2.c:304
#5  0x0000555555562b49 in controlFunctionHook (mcfg=0x555555b7b710, ctrlF=0x555555b7ef00, val=0 '\000') at ../src/midi.c:504
#6  0x0000555555562cda in notifyControlChangeById (mcfg=0x555555b7b710, id=34, val=0 '\000') at ../src/midi.c:542
..
---