Split Game into gamestate and UI

[nic-hartley]

Currently, Game has two jobs:

• Listen to messages and update the (user's view of the) game state
• Handle user input; based on that and the (...) game state, render the screen

This kinda breaks in networked situations, and several other features would benefit greatly from it. In #28 I mused about one way to solve this (having the Game be able to return a State at any time), but that doesn't solve the netcode issue -- or at least, it requires gamedevs to avoid a footgun, when there's a better way.

Briefly, Game gets split into GameState (for the first responsibility -- though it's a global, shared view of the game state) and PlayerUI (for the... UI). The gist is:

• We formally divide message processing into rounds. (They already are, but that's not ~officially guaranteed~ yet.) This will help anyway; introducing some ordering means you can make some assumptions that are convenient to be able to do.
• At the beginning of the round, the Game is cloned; the clone is passed to every Agent as it processes messages.
• "At the same time" -- maybe interleaved, maybe in parallel, maybe afterwards, w/e -- the original Game gets fed messages that the Agents are producing in this round. (So Agents will only see the Game as it was at the end of last round/beginning of this one, not as it's updated.)
• The cloned GameState gets passed to the PlayerUI -- and not any messages -- to render updates, ensuring it has the same view of the game state as agents in the current round.

This design lets us sync the GameState across all networked players separately from any UI state, which there can still be. But that can get stored locally and doesn't need to be synced. It also forces devs into a design where their world state they care about tracking is separated into the sync'd type, where the Game::state approach could let devs building the singleplayer first accidentally entwine a bunch of UI and game state logic and then have to untangle it later. Granted, this design suffers from the opposite issue as it risks UI state being embedded in the game state, but that seems like it'd be easier to untangle.

Actually implementing this is gonna be kind of a bear, but hey, at least I'm doing this nice and early while the engine is still fluid and easy to change!