This also only uses the draw length parameter if no motion
occured during the NoteCreateDrag. Otherwise it uses the length that was
dragged (which is subjected to a threshold).
When moving the mouse fast it can happen that the resulting
position (note_qn + dx) becomes negative. Which causes
tempo-map ramp calculations to fail and the application aborts.
a menu allows choosing between all markers or 1 specific type, and all ranges or 1 specific type
more work required on menu structure and menu options/dialogs to specify the type of new location
and range marker creation
The box outlines a given region, the grab position may be earlier
than the region's position.
Previously this caused a crash (uncaught exception):
```gdb
__cxa_throw () at /lib/x86_64-linux-gnu/libstdc++.so.6
Temporal::timecnt_t::timecnt_t(Temporal::timecnt_t const&, Temporal::timepos_t const&) at ../libs/temporal/timeline.cc:79
RegionMoveDrag::setup_pointer_offset() at ../gtk2_ardour/editor_drag.cc:2226
```
heap-use-after-free. Marker is deleted (and re-created), when
the tempo-map edit is aborted:
```
#0 0x7f77528ac017 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
#1 0x55f81062800d in TempoMarker::~TempoMarker() ../gtk2_ardour/marker.cc:794
#2 0x55f80ffb2fc0 in Editor::reset_tempo_marks() ../gtk2_ardour/editor_tempodisplay.cc:205
#3 0x55f80ffb2b19 in Editor::reset_metric_marks() ../gtk2_ardour/editor_tempodisplay.cc:185
#4 0x55f80ffb49fb in Editor::tempo_map_changed() ../gtk2_ardour/editor_tempodisplay.cc:301
#5 0x55f80ffbdf00 in Editor::abort_tempo_map_edit() ../gtk2_ardour/editor_tempodisplay.cc:850
#6 0x55f80fcf967a in TempoMarkerDrag::finished(_GdkEvent*, bool) ../gtk2_ardour/editor_drag.cc:333
```
Since no movement occurred, the tempo-map was not changed.
however we need to drop the lock and writable thread-pointer...
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.
Drag::_raw_grab_time is set to the correct time-domain. However
during ::motion() and other operations the adjusted time was
always AudioTime.
Most notably this caused editor->selection->time to have
different time-domains for start and end.
