State componentization

[johnameyer]

Rather than having a flat state for each game, refactor common functionality into separate components that can be chosen arbitrarily by games. Consumers should be able to expect a subset of the state (e.g. only {messages: MessagesState}). As well, use controllers to wrap each component so that only expected operations are performed and the state remains consistent.

[johnameyer]

With #63, ownership of modules no longer necessitates deserialization, just initialization, transformation, and validation. Still trying to figure out how modules can be built out of smaller modules without duplicating state across module children or exposing children modules to consumers.

[johnameyer]

New thoughts:

• underlying state is a flat object with keys pointing to a controller's data
• controllers wrap both their own state as well as other controllers, which they list as dependencies
• game defines list of controllers to use, as well as controllers to expose
  • only exposed controllers are in the resultant object

[johnameyer]

Still up in the air in the implementation:

• Allowing for subflows (e.g. trick controller could completely own trick flow with proper initialization)
• Allowing messaging (and other handles) in controllers
• Nicely handling transient state (e.g. the card to be played)