Refactor multiplayer room initialisation and context

[smoogipoo]

Overview

The primary purpose of this change is to enable the following change: smoogipoo@e24be0e - making the matchmaking background service able to initialise rooms and perform post-initialisation adjustments.

As part of this change:

• Room initialisation moved to ServerMultiplayerRoom.InitialiseAsync().
• ServerMultiplayerRoom constructor made private.
• MultiplayerHubContext moved to global singleton dependency.

This will also allow testing that users are eligible for the room, such as in smoogipoo@522ed4c

Important changes

This affects normal multiplayer room initialisation. In particular, the first user that joins the room will become the host of the room, and users are allowed to join in any order. Given that room join + creation happens sequentially server-side (as opposed to through a client-server round-trip), I don't expect this to result in too many race conditions (although still possible).

I think this is something that can be further improved by splitting out the JoinRoom logic. If agreed upon/requested I can try to do that in this PR - I think the scope of changes is https://gist.github.com/smoogipoo/de57193d7fa7077ea2cf163ac22ee988

Alternatives

I think this is the nicest of three possible directions I had in mind, the others include:

• Adding web-side/database storage for room users.
• Storing these "post-initialisation" states temporarily to an IMemoryCache and querying them on room init.

[smoogipoo]

Hold back on this for a bit, the resulting client-side code is quite flimsy...

[smoogipoo]

As of ppy/osu#35053, the client will still handle user join/leave via the normal flow. I suppose this one can still be considered on its own.