Library contracts

[johnameyer]

As the library has generally settled and common usages known, we should consider the higher form of the library as we look towards a 1.0 release. (This is a high level issue and doesn't contain anything specifically actionable, actionable tasks will be linked)

Things to consider:

• [x] Do the StateTransformer and ResponseValidator classes need to be exported? Would there ever be a case these would be overriden?
  • Considered in #47
• [x] Can we wrap more common functionality/boiler-plate into a class?
  • Considered in #47
• [x] Can we add a test to make sure everything is exported and proper?
  • Considered in #47
• [ ] Can we add hooks to the driver class to support open/close principal?
• [x] Can we decide how to handle the higher level abstractions and common functionality of the game like names and chat?
  • Moved to #60
• [ ] Can we clean up the ideas of sync vs async handlers and the queues?
• [ ] Can we make the handler <> intermediary <> presenter nicer and fallback if operations are not supported?
• [ ] Can we add a built-in package lookup/import by game type?
• [ ] Can we avoid including the web presenter/remove dependencies on console libraries?
• [x] Can we break out the state from being passed in the handler methods?
  • Nope, but we can change a protocol so that it is only sent before a change.
• [x] Can we make the game state iterator FSMs less verbose, more declarative? Redux-esque architecture perhaps?
  • Moved to #113

[johnameyer]

Current implementation thoughts:

• New generic class called GameManager in core which contains the common functionality
• Every package exports an instance of GameManager, and removes the other components from being exported
• Generally we want the onus of more complicated functionality to be on the less-implemented components, e.g. creating a new presenter, handler, or new game should be as simple as possible