Validation rework

[johnameyer]

As identified in #62

• [ ] Can we make validation more declarative - i.e. type matchers on fields, then high level validation if need be
  • hasCard
• [ ] Can we sharpen up our event validation the same way we are for states? Length checks, type checks, etc.
• [ ] Potentially implement message-type expectation validation (e.g. at this stage we are expecting only certain events
  • This may live better as a larger scale task about also clarifying the ordering of events, async ness, etc.

[johnameyer]

Likely worth thinking through whether we can re-use handlers in a generic way as well - i.e. discard events all are handled the same way.

[johnameyer]

Likely we should also use these validations in some form for the game-params i.e. type / range or other things that could be passed onto inquirer.

[johnameyer]

Core: isTurn, hasCard, nonnull, hasLength, isSuit

Situational: followSuit?

Composition: allOf/eachOf (asserting on each in array of values)

Others: not? (i.e. not(isSuit(H)))

A big question here is how the validators are parameterized - e.g. if we want to make sure the player follows suit, how is that suit provided? (long term - would it be done client side?) In situational occurrences do we pre-compute?

Additionally, there is the question of how to handle more complicated validations e.g. making sure a card cannot be played on any meld. While we could ad-hoc define these, that then limits the universality.

[johnameyer]

There's also a thought that since playing a card removes it from the hand there is a close relationship between the validation and the handling