Improvements around hairpins and dynamics, item snapping, alignment, staff centering, and autoplace

[mike-spa]

Resolves: #16845 (and much else)

• Lots of small improvements and fixes in the dragging behaviour of isolated hairpins and dynamics (dragging groups of aligned hairpins/dynamics still needs a lot more work, which I'm planning for following PRs).
• New code infrastructure to represent linked chains of aligned elements.
• New code infrastructure (collected in the AlignmentLayout class) to calculate the alignment of items, which is now done at the system-layout level, rather than the individual item level (and is also done more precisely).
• Improved implementation of the center-between-staves function.
• New logic to manage the cases where items need to centered between staves and also stay aligned to each other.
• New options to explicitely set whether hairpins should align or not with preceding/following dynamics (or preceding/following hairpins), with corresponding new UI.
• New options to align gradual tempo change lines with tempo text, with corresponding new UI.
• Small technical improvements and corrections to the Shape class.
• Introduced a score-wide value for minimum horizontal clearence in the vertical calculations of skylines. This is a temporary implementation: eventually the vertical spacing system will have a similar implementation to the horizontal spacing system with specific item-by-item values.

[mike-spa]

@RomanPudashkin the utests are fixed now. It's ready for review, when you can.

[RomanPudashkin]

I suspect that there will be 2 problems with this change:

1. these items may be deleted before the item storing them, so we will get invalid pointers here. And there will be no easy way to update the pointers, since these items probably don't have a parent-child relationship
2. I also suspect that these pointers might start being used quite uncontrollably to change item properties at unexpected times (i.e. for hacks). Adding const could help at least with this problem...

[mike-spa]

I totally agree. Unfortunately I can't see a better way of doing this at the moment. In order to achieve these engraving requirements the items need to be aware of each other in a non-const way, because they must be able to influence each other's layout properties, position in the score, and even UI behaviour (drop operations, dragging, etc). At the moment this works safely because I have made sure that these connections get reset and recomputed at every layout, which means they never survive editing operations, so they don't risk pointing to invalidated stuff. Also, they are stored in LayoutData which is never copied so that's also safer. But yes I agree that it's not ideal.

I did try to explore a different solution when I started: instead of having item A point to B and B point to A, create a new entity C which holds the pointers to A and B. But in the end I dropped it because it wasn't much better: C still holds pointers to A and B which could become invalidated; we would have to manage a large number of C items (one for every snapping-chain) which also adds performance cost; then who is the owner of C? etc.

I'm not sure that there is a "good" solution to this until our library uses only raw pointers. One day, these could all be weak_ptr...