Originally when popping in, the ReplayPlayer was loaded first (if previous screen was MainMenu), and afterwards the SkinEditor component was loaded asynchronously. However, if the ReplayPlayer screen exits quickly (like in the event the beatmap has no objects), the skin editor component has not finished initializing (this is before it was even added to the component tree, so it's still not marked `Visible`), then the screen exiting will cause `OsuGame` to call SetTarget(newScreen) -> setTarget(...) which sees that the cached `skinEditor` is not visible yet, and hides/nulls the field. This is the point where LoadComponentAsync(editor, ...) finishes, and the callback sees that the cached skinEditor field is now different (null) than the one that was loaded, and never adds it to the component tree. This occurrence is unhandled and as such the SkinEditorOverlay never hides itself, consuming all input infinitely.
This PR changes the loading to start loading the ReplayPlayer *after* the SkinEditor has been loaded and added to the component tree.
Additionally, this lowers the exit delay for ReplayPlayer and changes the "no hit objects" notification to not be an error since it's a controlled exit.
On cursor sizes below 0.3x it becomes exceedingly difficult to quickly locate and then accurately click the resume cursor on the pause overlay as it could as big as a handful of pixels. This clamps the minimum cursor size to 1x for the resume overlay, which is way more comfortable and more closely resembles stable.
This fixes an issue identified with the WASAPI implementation in
https://github.com/ppy/osu-framework/pull/6088. It has no real effect
on current `master`, but fixes a deadlock that occurs with the
aforementioned framework branch when one lets a preview track play out
to the end - at this point all audio will stop and an attempt to perform
any synchronous BASS operation (playing another track, seeking) will
result in a deadlock.
It isn't terribly clear as to why this is happening precisely, but
there does not appear to be any need to stop and seek at that point,
so this feels like a decent workaround even if the actual issue is
upstream (and will unblock pushing out WASAPI support to users).
