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.
Silencing an exception from a task continuation requires accessing
`task.Exception` in any way, which was not done previously if
`logOnError` was false.
To resolve without having to worry whether the compiler will optimise
away a useless access or now, just always log, but switch the logging
level. The unimportant errors will be logged as debug and therefore
essentially silenced on release builds (but could still be potentially
useful in debugging).
For better guarantees that `finalAction` is actually called on the same
screen that `checkCanComplete()` was (uses result of one
`getCurrentScreen()` call throughout instead of calling multiple times).