Basic authenication

Nobody has claimed this yet.

When a player enters the game a shell is created and this shell is given a process id. All actions the player performs on the OS level is done through this shell. Currently, the server does not authenticate users. It just places them directly in the game world when they request to join. It also cannot act upon the user on the OS level because it has no idea which shell belongs to the user.

The server should:
- Authenticate a player before adding them to the game world.
- Associate each player with their uid and shell's pid.

The following basic authentication flow should work:
1. Client connects to server and requests to join game.
2. Server generates and random token that can be used as a filename.
2. Server starts watching for that file in `/tmp`.
3. Server sends the token to client.
4. Client creates its shell connection to the server. This should connection should last for the duration of the client's session.
5. Client creates a file in `/tmp` with the name token and contents being a single line containing the shells pid (i.e. `echo $$ > /tmp/`).
6. Server detects that the `/tmp/` file was created. It then checks the uid of the files owner and reads the pid.
7. The server checks that the pid is owned by the same user that owns the file (this introduces a modicum of security).
8. If everything is ok, the server registers the pid and uid of the user against the clients network id and adds the client to the game. If not ok the client is rejected.

Start by locating the server's join-game handling and the code that creates each player's shell connection. Trace how the client and server communicate during session setup, then implement and verify the stated token, /tmp file ownership, UID/PID matching, registration, and rejection flow.

Written by the indexing model from the issue text.