This used to already be the case prior to b419ea7, but in a very
roundabout way. Changes to the value of the star difficulty bindable -
including indirect changes via the set of active mods changing - would
trigger the wedge display to regenerate and load asynchronously.
b419ea7 accidentally broke this by moving down the bindable retrieval to
a lower level, at which point `WedgeInfoText` would only receive the set
of mods selected at the time at which a given beatmap was selected, and
not receive any further updates, breaking the BPM display updating in
real time (as `WedgeInfoText` could not be aware that rate-changing mods
were even in effect).
To resolve, explicitly reload the wedge's contents on mod changes.
This fixes the whole issue behind `Ruleset.Value` being null, by
updating `Current` on BDL rather than waiting for the base logic which
executes at `LoadComplete`.
This seems like something that should happen at the base `TabControl` class itself, by switching `Current` right after the first added tab item, rather than doing it on `LoadComplete`, but I'm not sure about changing framework logic outright, so fixing this locally until it occurs on other places.
Intentionally not using `[Values]` as the scale modes can be applied to
the running game instance directly, rather than recreating it all over
again.
The same could be said for the notification overlay but not sure, seems
like something that should be considered at an `OsuGameTestScene` level
instead (whether the same game instance can be reused for further
testing).
By using `Content` instead, now the logic will get the X of the settings
overlay at the `Content` space, which can be scaled in the
`ScalingMode.Everything` mode.
And in the case of `ScalingMode.ExcludeOverlays`, a subcontainer
somewhere inside `Content` that's holding the screen stack would be scaled,
but `Content` won't be affected which is what we want in that case.
