lobby.gd had gotten big, bloated, ugly, and hard to read. It needed a
refactor. The first thing I did is split up the *GUI* into the logical
steps it should be. So the new flow is:

 - Start the game
 - Click "Quick Play"
 - Matchmaking begins on my dedicated server

 - Start the game
 - Click "Custom Game"
 - *Only now* am I presented with server / client options

 - Start the game
 - Click "Singleplayer"
 - Singleplayer

NOW, and only now, and NO MATTER WHAT PATH I TAKE, I am taken to the
*lobby*, which now is where I:
 - Choose my name
 - Choose hero
 - See list of players
 - Get my team assigned
 - Anything else that I might like to put in
The point here is that this has *nothing* to do with handshaking /
matchmaking / etc! This is just part of the game! At this point I have
*already been connected* to the server. I've already been aquainted with
my other players. The game has begun.

I put the things that don't belong in any of these flows in
networking.gd, a sort of model-view sorta thing. All of these flows use
some sort of networking thing like `init_server` that tbh should be
*completely* abstracted from the UI.

It's totally a WIP!!! Above is the IDEA, but below is what I've actually
*done*:
 - Made the scenes, made a passable UI for each one that at least
 indicates ~what they'll do
 - Made the corresponding scripts, and split up the lobby script into
 ABOUT where I think it'll end up, but no promises
It still errors all over the place, and it's nowhere near properly
organized. PLUS, I'd also like to rewrite a lot of the code / rename
things as part of the initial refactor goal of making me able to
actually think about networking.

The problem I just encountered is that I have to tell the players who
are currently skirmishing that they have a game. This means either:
 1. Telling the skirmish server to move them
 2. Keeping a connection with players
 3. Running the skirmish server on the matchmaker!
Three sounds nice because the matchmaker is sitting on this godot
instance, it might as well do something with it, right? But it's
essentially equivalent to 1, it just doesn't have to think about
networking because they're the same instance. So moving from 3 to 1 if I
realize it's a bad idea is easy, but 2 becomes pretty entrenched.

You're making some pretty big decisions here, take it slow.

Also allows subsequent connections, but it's broken. Don't tell the git
gods that this commit is a lie

This will make testing MUCH better, I do believe.

Also, levels now inherit a level object

Also add variation in spawn point, so that all spawns are not on top of
each other

There however were some bugs that came with this, so I'm switching to
master to explore this.

That is, even if there are less than MAX_PLAYERS

Previously, everyone thought everyone was master, and it resulted in you
controlling each player. Now you are only the master of /your/ player,
so multiplayer works as expected.

This is the real initial commit with all the code I have until now.

Networking: A server and 2 clients connect and then control their
players. This is still buggy. For example, every client controls the
/same/ player.

FPS controls: WSAD, Jump, and Look with mouse are all implemented (Taken
from Caliou's demo). This includes collisions.