This involved a significant change in event handling for automation region views,
but it brings it into line with how it works for other things. On button press
we initiate a drag, then if no motion occurs, the Drag returns false during
finalization, and only then do we continue through Editor::button_release_handler()
to eventually end up in ::add_automation_event().
Although it is a substantial change, the fact that it now works the same
way for audio regions, automation regions and automation tracks seems
like a definite plus.
I do not understand why this works, but all of this code related to MIDNAM
model names is just a total mess in terms of rational design (caused, in turn,
by MIDNAM's design, which might possibly reflect the real world).
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
In layered mode the scroomer is not usable with stacked MIDI regions.
Ideally we'd only hide it if there is more than one layer
but that is for another day.
When adding a note, use these criteria to choose the channel number:
* if the user has explicitly specified a note in the pulldown, use that
* if the user has AUTO selected and we are in a region, choose the nearest note's channel (consistent with velocity behavior)
* as a fallback, query the track for its channel-filter (old behavior)
This supersedes 0708cdb6b4, an explicit `name_label.show()`
is not needed. The inactive label was missing an explicit call
to show.
This also fixes MIDI track MIDNAM Selector visibility
This removes various duplicate code-paths leading to midi-model
updates, and expensive context-menu rebuilds. This significantly
speeds up MIDI track creation.
