This is quite a breaking change, but I think it is beneficial due to the large amount of usage of this class.
I originally intended just to remove the allocations of the two delegates handling the `Changed` flow internally, but as nothing was really using the bindables for anything more than a general "point has changed" case, this felt like a better direction.
I was trying to be too smart with caching, but if the `Play` method was
not called often enough it would have a recent reference. Unfortunately
this requires a separate query to `Entries`, but is also a special case
(no future hitobjects).
This also removes the time-based checks (result status alone should be
all we care about).
This changes the fallback logic to always prefer the previous resolved
lifetime entry rather than fallback to the first entry ever. I think
this is more correct in all cases.
Also rewrites the inline comments to hopefully be easier to parse.
Three bindables are left which don't have this overriden due to them
already not having a value-only constructor and not supporting
`GetBoundCopy()` properly:
- `BeatmapDifficultyCache.BindableStarDifficulty`.
- `TotalScoreBindable`
- `TotalScoreStringBindable`
I could add support for them by passing the required data to them, as
they seem to be able to have that shared, but I'm hesitant to support
something which was already broken and never used, not sure.
This was causing any `ValueChanged` event bind (such as the one in
`SettingsItem` to invoke `SettingsChanged`) to be overwritten when
`Current` is set afterwards.
- make `UserActivity.InGame` and derive that to `InSoloGame` and `InMultiplayerGame`
- rename `SoloGame` to `InSoloGame`
- rename `MultiplayerGame` to `InMultiplayerGame`
With the previous commit, the transform application is skipped when the state is already changed. But it turns out the previous commit breaks slider animation in the standard editor. This is probably due to the transforms are applied before nested hit objects are added.
