fix #286616, fix #287432: handling of header/trailer on mmrests

[MarcSabatella]

A few more issues involve extra key signatures or other elements appearing on certain operations involving multimeasure rests. See https://musescore.org/en/node/286616 and https://musescore.org/en/node/287432. There are a few other glitches fixed by this that didn't seem worth submitting additional reports for.

Three main aspects to my changes here, involving the handling of header & trailer elements when creating mmrests:

1. link any non-generated clef, time signature, or key signature between mmrest and underlying measure
2. set the ENABLED and HEADER/TRAILER flags on the segments when copying elements
3. set the HEADER/TRAILER flags on the mmrest itself

[MarcSabatella]

A few tests need to be updated for the linking of elements in mmrests.

[MarcSabatella]

The diffs on the tests are probably OK, but I do want to check on the "indexDiff" tags, because I don't fully understand them. @dmitrio95 , I have read about them in your blog from last year and get that they shouldn't be needed often, but I'd like to understand better when they are needed. What about the fact that I am linking time signature between the original measure and the mmrest requires the indexDiff? Is it just having the link on the same staff in the same score as opposed to a linked staff or part? Any reason I should be concerned?

[dmitrio95]

Those <indexDiff> tags in mtest diffs look OK. The <indexDiff> tag exists to distinguish between the elements at the same score and the same position, and those time signatures have positions that cannot be distinguished with measure number, tick, track etc. So it is OK that such a link requires <indexDiff>, otherwise the second time signature wouldn't find the first one to link with it.

[MarcSabatella]

OK, thanks, I've updated the references.

[MarcSabatella]

FWIW, I think this probably just came up again on the forum in https://musescore.org/en/node/289226#comment-922066. I hadn't noticed until after the RC that this one missed the big merge last week. I'd consider it very high priority for whenever we start considering fixes that aren't regressions versus 3.0.5.