Bad layout of pages >1 after edit

I can reproduce similar behavior from scratch as well:

1) new score, treble clef template, 400 measures (really, any score that extends to two full pages)
2) add spacer down to first measure
3) extend far enough to push two systems to next page
4) delete the spacer

Result: too much space at top of the second page, and object debugger similarly shows systems belonging to multiple pages

I now think it has to do with how we initialize the system list when starting to layout a page, we're still thinking the previous system is there when it shouldn't be.

I can reproduce these effects going back to the alpha, which is the earliest build I have. The only somewhat relevant change to the code I see within the past year was https://github.com/musescore/MuseScore/commit/d8fa8f8c6237f989e345e1379…, but I don;t see anything in the way the code was structured before that to lead me believe this ever worked. What I think we need is the equivalent of "systemOldMeasure" to track when we've reached a page that hasn't changed - "pageOldSystem" or some such. Or just keep collecting pages for the sake of recomputing system positions, not actually laying out the systems. But that means doing a bunch fo skyline calculations we don't need to be doing, so better to figure out when to stop.

The msot relevant place to do it is the line Dmitrio flagged as FIXME in the referenced commit, but that does appear to be what the previous was doing as well. There just doesn't seem to be a place where we realize we need to continue updating systems until we reach a page that hasn't changed. So I will look at adding code for this.

I have it working, pretty simple fix, but want to continue testing in the morning.

https://github.com/musescore/MuseScore/pull/5081

I have updated the title to reflect the true nature of the problem. In short: if edit affects the height of a system enough to change the number of systems that fit on that page, we don't bother re-laying out the next page. So if a system should move to the next system, it just disappears:

Conversely, if a system should move from the next page onto this page, a hole is left at the top of the next page where the system was, and the remaining systems end up being stacked directly on top of each other:

All that is needed to fix this mess is a change to end condition for the page collecting loop, to check that we really are done with the range and that the page ends with the same measure it did on the previous layout, so that is what my PR here does.