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.
When changing the ruleset at song select, there was a scenario where it
would be set to default (empty) for one debounce length where this was
not actually required. This occurs when the currently selected beatmap
set has other difficulties which match the target ruleset, specifically.
This brings back the ability for the carousel to scroll in a classic
way. It turns out this is generally what we want for "seek" operations
like "random", else it's quite hard to get the expected animation.
I did experiment with applying the animation after the pooled panels are
retrieved, but in a best-case scenario there is still a gap where no
panels are displayed during the random seek operation.
In the case of automatic scroll requirements (ie. scroll to selected) we
are delegating the animation logic to the panels themselves. In order to
make this work correctly, the scroll operation needs to take effect
before any animation updates are run.
This was causing multiple issues with masking and sizing and really
didn't need to exist in the first place. Also not sure why the pool was
nested inside the scroll container, but it isn't any more. Probably for
the best.
