Muxml: emit finger layout

[algorithmiker]

Tabs contain an implicit finger layout, which we do not use at all right now.

Add a -f flag with values all|none|smart.

• all should emit the active finger for all notes (but not the base string, as that would clutter up the score)
• none is the current behaviour
• smart should, for every note, calculate the distance from the previous note (Manhattan/Euclidean distance should do fine), then emit a finger position and the base string if the jump is too large.

[algorithmiker]

Maybe the best (most "human-like") would be to keep track of where we are on the neck of the guitar (as a 22x6 grid, 22 is the x axis), as following:

• initialize a 5x6 table with zeroes.
• initialize xSection to zero.
• for each note(string, fret) played:
  • if |fret-xSection|>5
    • xSection=fret
    • re-initialize the "played" table with zeroes
    • add string and fret to the score
    • continue to the next note
  • if table[string][fret] is zero,
    • add fret (no string indication) to the score
    • mark table[string][fret]=1.

The best implementation of this table should be benchmarked between:

• an array of arrays, eg. [[bool; 6]; 5]
• a flat array, eg. [bool; 30]
• a bitset on an u32.

Either way, this should be gated behind a flag
The options for -f would then be:

• all should emit the active finger for all notes (but not the base string, as that would clutter up the score)
• none is the current behaviour
• x (or some better name): label only the section changes, with string and fret, so the first half of the logic, without the table
• xy (or better name): this logic.

xy should be default in #12 - auto mode.
Either way, this requires a restructuring of the current muxml backend, because we lose the fret information when converting to MuxmlNote2

[algorithmiker]

I've implemented the xy mode from above.
Its most obvious pitfall is that there are many cases where you want to begin the active section with a non-0 finger, eg. beginning with the 3d finger in VII, but being in V for the rest.
A simple fix for this would be to have a separate "section" pass, where it quantizes any sections within 4 distance to the same (maybe even to 3,5,7,9,12,15,18)?

[algorithmiker]

Maybe it isn't worth it to bother with assigning fingers to notes.
Muxml has native support for tabs, maybe we should just emit that.