[MU3 Backend] ENG-34: Fix erroneous space created for melismas

[iveshenry18]

(Partially) Resolves: ENG-34: Improve lyrics spacing

Previously, melismas were treated the same as normal Lyrics in terms of
horizontal spacing—they would cause a spacer to be added to the
ChordRest to which they were attached, causing an unnecessary gap after
the first note of a melisma.

This commit prevents a melisma from adding a right spacer to
their first ChordRest, and rather creates a right
spacer on the last ChordRest of a lyric if necessary.

In pursuit of this, this commit refactors ChordRest::_melismaEnd(s) from
a bool to a std::set<*Lyrics>, giving a ChordRest a way to access the
melismatic Lyrics that end on it. This change also solves the problem of
said bool being untrustworthy (i.e. erroneously being changed to false
when one of multiple melismas was removed).

• I signed CLA
• I made sure the code in the PR follows the coding rules
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code
• I made sure the title of the PR reflects the core meaning of the issue you are solving
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
• I made sure the commit message title starts with "fix #424242:" if there is a related issue
• I created the test (mtest, vtest, script test) to verify the changes I made

[RobFog]

And another one for @lvinken 😉

[vpereverzev]

just use the combination of "std::set<Key,Compare,Allocator>::find" and "std::set<Key,Compare,Allocator>::erase"

I'm also not sure if whether it makes sense to store it in std::set, what was the point?

[iveshenry18]

Good call; I honestly can't recall why I made this so overly complex.

The reason I'm storing the values is this: previously there was a _melismaEnd boolean that stored whether a ChordRest had the end of a melisma, but this actually was unreliable if there were multiple lyrics. Additionally, this spacing fix required that a ChordRest have pointers to any lyrics/melismas that end on it in order to create a properly-sized spacer. Since I needed to store those pointers and there already was an existing melisma-end data member, I basically made a drop-in replacement for the existing _melismaEnd functions that stored all pointers (realistically, this will be ~0–3 values) rather than just setting a boolean.

I chose a std::set to avoid redundancy (since I didn't write the original code where they get added); although possibly an unordered_set would be quicker, or some other Qt container. Does that make sense? Let me know if I'm missing something

[vpereverzev]

ah, sorry, missed that one in my emails

prefer to use std::containers wherever it's possible within the libmscore
regarding your case, I think it's enough to stick with std::set then