This makes "sequential" more or less mean an octave vertical interval,
but only for in-key mode. For chromatic mode, "sequential" is still just a
naive wrap-around layout for every note.
This juggles the implementation slightly in a way that's more resilient to
mistakes: the representation of pads in the surfaces is always fully reset
before setting up the grid, and a state message is sent for every single pad
once after the scale algorithm sets things up.
This means that scale algorithms don't need to deal with hairy edge cases like
running off the end of the scale or the valid range of MIDI notes.
"Mostly" because there are still some issues with horizontal overlap between
entries, but I think that's something that needs to be addressed separately.
Like earlier issues, this was caused by using a screen-derived or default
cairo/pango context. I also tinkered with some constants to make things look
sensible to me, and hopefully everywhere since it should always look the same
with the context fix.
We no longer have a distinct "position" property, because the "length" property
defines both extent and position. But we must not call ::recompute_at_start()
when the position has not changed, so here we use Region::last_length() to
simulate the position property.
These were preventing Ardour from compiling on Windows (Clang or MSVC)
Possibly would've been buildable with MinGW but I don't have that available to test.
Tests showed
ControlSurfacesTest: Tascam US-2400
: [ERROR]: Unknown button ID "F7"
: [ERROR]: Unknown button ID "F8"
This is trying to mitigate it blindfolded.
It doesn't seem like Tascam US-2400 has more than 6 buttons, so it seems
like the profile has been incorrect since it was introduced in 937efdb6.
(But as pointed out in e6de7957, it seems like the profile often isn't
installed and button assignment thus isn't used.)
