Initial multiplayer backend

The long-awaited backbone of the game that enables worldwide communcation. It's all right here at your fingertips!

### Socket events for the lobby
- [x] From client: Creating a room
- [ ] From client: Joining and leaving a room
- [x] From client: Start game (exclusive to first of the player list)
- [x] From server: Room updates (new joins/leaves/chats/game starts)

### Socket events while ingame
- [x] From client: Client updates (specific actions similar to commands)
- [x] From server: UI and game data synchronization updates (sent to all players at the start of intervals referred to as rounds)
- [ ] From client: Sending action updates to server

### Server handling in general
- [x] Save all game data in the room as objects with the key being the room ID
- [x] Ordered list of players (mostly so that the game can be started even if the first player disconnects)

### Server handling while ingame
Respond to the following client update headers and update the room object accordingly:
- [ ] Player has spent a die on a plane to schedule a level switch (Alternatively: Player has spent a die on an *access point*)
- [ ] Player's plane successfully destroying an enemy plane
- [ ] Handleing synchronization between server and clients

The above list is non-exhaustive and will likely change as the development progresses. Thus the issue is only used as reference for this first stage of development, and new issues should be created for future changes to the list. Actual server computation is also not considered for this list; check the box when its call-and-response template is in place.

Additionally,
- [ ] Save all die values and plane positions in the room object to prevent client-side code injection cheats
(Technically already part of the "save all data" checkbox above, but it needed to be emphasized)

No files, tests, or entry points are named. Start by locating the existing client and server socket handlers and room state, then compare them with the unchecked lobby, in-game, synchronization, and anti-cheating items; the issue does not define a bounded completion point because the list is explicitly non-exhaustive.

Written by the indexing model from the issue text.