Render lilypond24a

[jaredjj3]

This PR renders lilypond24a by adding support for rendering grace notes. I used the reference implementations in vexflow gracenote_tests.

Divergences

• lilypond incorrectly renders a slur when there is a grace slash.
• vexml incorrectly renders succeeding grace notes (last note in measure 2).
• MuseScore 4 incorrectly renders a slur.
• Guitar Pro 7 does not seem to always render the correct grace note duration.

lilypond

vexml

osmd

MuseScore 4

Guitar Pro 7

[jaredjj3]

The current approach collects grace notes while accumulating context to make rendering.Note, rendering.Chord, and rendering.Rest objects. This works fine when grace notes are exclusively before the note they're modifying. However, the end of measure 2 shows that this isn't universally the case, since there's a grace note after a note.

I've made a lot of effort to avoid "lookahead" logic in rendering, because it tends to add a lot of complexity on an already-complex module. I'm going to try to solve this in the data layer, similar to how chords are rendered. In the musicxml.Note object, I'm going to add a getPrecedingGraceNotes(): musicxml.Note and getSucceedingGraceNotes(): musicxml.Note methods. If the musicxml.Note is a grace note, these methods should return empty arrays. Otherwise, I can perform the "lookahead" to see if a succeeding grace belongs to the note in question.

[jaredjj3]

@rvilarl, when you get a chance, take a look at the vexml rendering in the first comment. There are two things I notice:

1. Setting a position on a vexflow.GraceNoteGroup doesn't seem to affect it. For succeeding grace notes, I'm setting the position to vexflow.ModifierPosition.RIGHT, but it's still being rendered on the left (last note in measure 2).

2. When an accidental is set on a grace note, the scale seems a little large for it — especially when compared to osmd and MuseScore 4.

I think these are both very minor issues, so I thought you'd be interested.