Fix 1 million score being unachievable on some mania beatmaps

[bdach]

RFC. Closes #23911.

I'll level with you, I kinda hate this diff, but I'm not sure how to do better given the constraints in place. The constraints in question being:

• We want to be using Score V2.
• The value of Score V2 for a play depends heavily on ordering of judging objects, due to the combo component of each object's score being tied to current combo after judgement of said object.
• Therefore, autoplay simulation must match actual gameplay 1:1 wrt judgement ordering for 1M score to be achievable by the user given perfect gameplay.
• Using gameplay code for autoplay simulation is infeasible for reasons of (lack of) speed.
• Judgements are scored individually by each drawable hitobject.
• Therefore, the specifics of judgement ordering depend heavily on the implementation of a ruleset.
• Changing the above (so that order of judging during gameplay can be somehow centralised to one place that decides order of judgement) requires rewriting every ruleset ever.
• In mania specifically, during a single update frame, notes are judged before ticks. This is due to the implementation detail of note hits/releases being triggered by IKeyBindingHandler<ManiaAction>.On{Pressed,Released}() (1, 2), which is being handled by a parenting KeyBindingContainer + InputManager, which propagates input events to the notes earlier than they can actually be updated themselves (due to being their parent). Ticks are judged via the normal UpdateResult() flow, in DrawableHitObject.UpdateAfterChildren() (3).
• The above means that attempting to apply any sort of non-ruleset-specific fix in JudgementProcessor (which I thought I may be able to do but which ended up failing) is fooling ourselves, as there is no guarantee that every ruleset ever will follow this particular judgement ordering. Which is why I opted to expose a method that mania uses exclusively to jiggle autoplay simulation order into the order that it needs things to be in to match actual gameplay.

None of this is even touching the issue of inter-column judgement order dependence, as for the matters of autoplay it has no bearing on the final result (to figure out why, consider that all judgements that happen on the same time instant and receive the same score are basically interchangeable, so they can be reordered in any way among each other without influencing the end result). But that is absolutely a concern for actual gameplay where judgements may not be perfect.

[bdach]

Someone reported on discord that a graved osu! map also has an issue where 1M score is unachievable, and it's because this implementation is still naive (relies on no concurrent objects to work correctly). I could go and fix that case here by partially mirroring the mania implementation (flatten all objects, sort by end time) but honestly not sure it's worth the performance hit for a graved map.

[smoogipoo]

I wouldn't be against this since it's to guarantee correctness. The performance hit shouldn't be noticeable. But the current changeset is also fine for now.

[peppy]

I think this is fine for now. We're probably going to come across more cases that need addressing (aka judgements which change ordering due to how the user plays the beatmap – one of the things we solved with the old standardised scoring but alas) but small steps forwards makes sense.