Fix intermittent failure in screen navigation tests

[frenzibyte]

TearDown : System.AggregateException : One or more errors occurred. (Cannot invoke BeginPlaying when already playing)
  ----> System.InvalidOperationException : Cannot invoke BeginPlaying when already playing
Data:
  Sentry:Mechanism: AppDomain.UnhandledException
  Sentry:Handled: False
--TearDown
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at osu.Framework.Extensions.TaskExtensions.WaitSafely(Task task)

https://github.com/frenzibyte/osu/actions/runs/3913119373/jobs/6688620934
https://teamcity.ppy.sh/test/2989819594862160493?currentProjectId=Osu&expandTestHistoryChartSection=true

See #22220 for more information. I've included two changes here, one for handling restarts on TestPlayer instances by enforcing EndPlaying before exiting screen (extra safety in addition to disposal logic), and another for the failure in TestSceneScreenNavigation specifically, since that one is based of a full game instance, which would use SoloPlayer instead of TestPlayer.

Not fully confident on the test-side fix (dumpster fire for sure), but I can't think of any better way for it so...

For reproduction, simply add a task delay in SubmittingPlayer.OnExitting before performing score submission.

[bdach]

Mixed feelings on this. I could live with the fix, although the fact that now all player tests differ in behaviour to the actual game - which also includes TestScenePlayerScoreSubmission - worry me a little bit.

[bdach]

What's this modifier change for? Nothing new appears to be using this.

[frenzibyte]

Leftover change (boring details is: wanted the test to make sure player called BeginPlaying before ending it, but realised I could guarantee it by just ensuring player fully loaded).

[peppy]

In the interest of keeping momentum and reducing developer frustration I'm okay with this. It's very clear that we need to address this in a better way, but that can wait, in terms of priorities (tracking via #22220).