PlayerStore and DeckContext both track player hands redundantly

[codegard1]

PlayerStore is over-engineered for what it needs to do. We use it as a class because then we can call methods directly from instances of Player, but this overlaps too much with GameContext and DeckContext, which is where all of the effort in game logic has gone so far. It would be better to reduce PlayerStore to a type and to manage players directly as plain objects in the gameState, so that there is no confusion about where player hands are being managed and evaluated.

[codegard1]

Counterpoint to the original comment:

• While PlayerStore overlaps with DeckStore in that it also tracks player hands, otherwise it is still a useful way to add callable features to the player object that makes it worth keeping. If anything we should just remove the ability of PlayerStore to track player hands, and rely entirely on DeckStore for that instead.

[codegard1]

This issue will be resolved when all logic referring to player hands is consistent in its data source.

[codegard1]

We want to avoid making Players a class of their own because then it becomes less straightforward to save and load their state from localStorage. We can use a class (PlayerStore) to manage objects of the Player type instead, localizing functions that are specific to players in the Store while the players themselves are just plain objects. Hence we should deconstruct the Player class and move its class methods up into PlayerStore, and then update any references to the Player class to refer to PlayerStore instead, or to modify the player object directly instead. Also, we'll need to consolidate the Player type and the interface IPlayer to reduce redundancy. If there is no Player class then we don't need an interface for IPlayerState, for example.