Closes https://github.com/ppy/osu/issues/21732.
While the problem of multiple judgements in one frame and ordering of
`RevertResult()` calls as described in the issue is a real one, this
commit is a bit of a sidestep of the entire issue.
The idea here that while *snapshots* of instantaneous combo values are
susceptible to such ordering foibles on revert, *deltas* are not - and
such, when deltas are using to update the combo counts on revert,
ordering stops mattering so much.
This fell out of my work on hit window-related replay issues. In my WIP
branch (that is probably going to get PR'd as draft soon) I refactored
`HitWindows` and found a few straggling test failures due to some places
reading hit windows for results that were not actually supported by the
underlying `HitWindows` implementations, leading to returning garbage
(mostly zeroes).
Importantly, there is one actual usage in game code with impact here -
`TaikoModSingleTap` was attempting to read the hit window for MEH, when
MEH was never actually a valid hit result in taiko (OK is). This was a
result of a copy-paste oversight from osu!, specifically from
https://github.com/ppy/osu/blob/51cf835fb6300aca53b5b98143d606f64d7a4d49/osu.Game.Rulesets.Osu/Mods/InputBlockingMod.cs#L58
The `EventCount` variable wasn't factoring in that some results do not
affect unstable rate. It would therefore become more incorrect as the
play continued.
Closes https://github.com/ppy/osu/issues/31712.