Culls another non-thread-safe mutation of the `Playing` bindable.
It seems to be a weird vestige from an earlier revision of the old
"direct" panel, which relied on `DisposeOnDeathRemoval` to finish track
playback (and then was removed in
6c150c9ed7). The play button is no longer
responsible for managing preview track lifetime anyway;
`PreviewTrackManager`'s method are intended for that.
Revealed by the framework-side transform thread safety checks. `Stopped`
is even annotated as not being thread-safe (but was annotated as such
long after the class's nascence).
In theory this seemed like a good idea (and an optimisation in some
cases, due to lower fill rate), but in practice this leads to weird edge
cases.
This aims to do away with the operations on external drawables by
applying a dim to the area behind the `LoadingLayer` when required.
I went over each usage and ensured they look as good or better than
previously.
The specific bad usage here was the restoration of the colour on dispose
(if the `LoadingLayer` was disposed in a still-visible state).
I'm aware that the `BeatmapListingOverlay` will now dim completely during
load. I think this is fine for the time being.
It turns out there's some quite convoluted scheduling / order of
execution requirements of ModSelectOverlay and ModSection. Applying
scheduling causes a runaway condition ending in zero frames after many
mod button changes.
I wanted to avoid rewriting the whole component, so have just moved the
schedule to guard against the part where drawables are actually changed.
There are 3 modes: enabled, limited, and disabled.
The limited mode hides identifiable information such as username, rank, and
(if participating in one) multiplayer lobby name.
