[client] Regularize the synchronization of views across players

[joshuaauerbachwatson]

In the initial design for the game, there was a "show" button and information was only propagated from the current player to the others when either "show" or "yield" was pressed. I dropped this design both because it was confusing and error prone and also because, in the absence of any enforcement of rules by the game, I thought it was important for players to see the current player's moves as they were made to catch mistakes and suppress any temptation to cheat. Unfortunately, some holes were left by this change.

1. During the setup of the game, not everything gets propagated correctly.
2. Since animations are purely local, we can't propagate until the end. This is almost certainly ok, but we need to evaluate the human factors and be prepared to change.
3. When cards or boxes are dragged, it has proven to be a bad idea to propagate each time the dragger is entered because it results in too much message traffic. We need to determine whether waiting until the end is better or propagating periodically (either based on elapsed time or degree of movement) is better.

To fix these and possibly other loose ends, I propose that

1. GameState construction should be simplified so that the setup phase is no longer so special. Rather, all sent GameStates should be the same and include all possible information.
2. The program must be thoroughly audited to find all the places where propagation is required and the necessary refactoring should be done to make this easy to reason about.

[joshuaauerbachwatson]

The game by its nature is not quite ideal for "model view controller" separation, because any useful model of the game would have to include card positions relative to the background, which is arguably "view like" information. But, it is also essential information (must be in the model) since there is no abstraction of the actual game being played (only the players know that).

I went rather far in making a virtue of this situation by abandoning MVC altogether. The canonical state of the game is kept in the UIView subview hierarchy, with the bounds of each card defining its position. Even the membership of cards in boxes is calculated from the layout rather than recorded directly.

Another design decision was to treat server-based communication and multi-peer communication as equivalently as possible which means that we cannot rely on a client/server split with the server holding the model of the game. The player whose turn it is holds the model and is responsible for both changing it and broadcasting it to the others (with optional assistance from the server).

I have considered changing the design to be more MVC-like but ended up deciding to double down on the current design. So, the ViewController object (which holds the UIView hierarchy) also holds other aspects of the game state and is going to move in the direction of becoming a more perfect representation thereof. The GameState object is simply a convenient encoding of that state for transmission between devices.