By passing the current text of the automation button we can make the
dropdown menu align with the current mode. This will only work for
full-size automation buttons, not when use-knob is true, but in that
case it feels wrong to popup on top of the button anyway.
Also make the menu show on mouse down like a real dropdown.
The code computing the position of the popup menu used to compare the
given string to each MenuItem::get_label() result, but that method
actually replaces the content (child) of the MenuItem if that child is
not already a Gtk::Label. In particular, this breaks menu separators.
Avoid the issue by checking by hand if the only child of the MenuItem is
a Label, and directly compare the label text.
Because all uses of the function positioning menus anchored to a widget
were as callback argument to Gtk::Menu::popup() where the caller needed
to correctly bind arguments, this led to repeated and a bit obscure code.
Wrap the logic into an helper function that takes care of all that, and
update the callers.
This mostly fixes an issue with notifying plugins about tempo-ramps
and BPM changes.
remaining to be fixed (in tempo.h):
```
_session.tempo_map().metric_at(frame_position).tempo().beats_per_minute()
```
currently returns the most recent *fixed* tempo at or before
`frame_position`. All other Plugin types are affected by this as well.
- it is currently dual use (move both ends of a range marker
during drag / push control points at the beginning of a drag).
this may have to be separated, but as it is called the push
points modifier, it belongs here.
- don't alter region frame length on tempo change or position change.
- set region _start correctly (see comments) on tempo map change.
- ensure audio-locked region's beat is set on tempo map change
- audio-locked midi regions can be start-trimmed properly
when close to 1|1|0
- a midi region placed before the first meter
will continue the tempo curve and first meter.
Only a couple of callers require change, as bbt_at_beat() already
deals with this.
