[Regression] Bad layout of beam in presence of cross-staff beam in another voice

See #289492: [Regression] Bad layout of slurs in presence of cross-staff beams for some background, and https://musescore.org/en/node/289471 for the original report. Basically, though, we have issues with layout in the presence of cross-staff beams, because they involve an initial layout based on a guess as to final stem directions, and then a second layout based on the actual stem direction.

Here's a simple reduction, showing first how it looked in 3.0.5:

and now in current master:

Depending on the specifics, you can also get the beam being too short instead of too long. To be fair, it was also possible to get 3.0.5, and 2.3.2 for that matter, to do bad things, if you worked hard enough.

This case is particularly thorny because it's not even the cross-staff beam itself that is laid out badly - it's a perfectly ordinary beam, laid out badly because of a cross-staff beam in a different voice. That's because during the initial layout, we thought both sets of beams would have the same stem direction and overlapped the chords with that in mind, but on the relayout we needed to shift the non-cross-staff beam. And at that point, the layout of that beam is finalized, because it's the voice 1 beam, and it was laid out in full before we discovered the voice 2 notes need relayout, and it's the relayout of the voice 2 notes that caused the already-laid-out voice 1 notes to be shifted to the right.

The fix I am currently preparing acknowledges we can't know the stem direction for notes on cross-staff beams, so rather than use the "currently guessed" stem direction for chords on cross-staff beams, we calculate our own stem direction and just use that, so we use it consistently. The algorithm produces the right answer in most cases, but what's better is that even when it's wrong, it's wrong consistently, so we get the same chord offsets on both passes no matter what. So there may be places where people quibble which of two overlapping chord we put to the left of which (not that there is much basis for an objective decision with the combination of overlapping voices and cross-staff beams), but the beams will look nice, and you can always adjust the notes.

I should note a more comple fix is probably possible, where instead of processing beams one at a time as we process tracks sequentially, we could choose to first collect the beams for a given staff, then just do the chord relayout for all chords, then complete the rest of the beam layout. but that's a bigger refactoring than I have the stomach for at this point.