What I did:
*Server can (and does) now receive controller objects from all of its
participants.  The methods actually take a participantList as an
argument, so in theory, different lists could be manipulated (perhaps in
a multi-game future).
*Server can (and does) apply the controls to all players in a list of
participants, then updates its server game state.
*Server can (and does) write its ServerGameState to all participants in
a participant list.
*Clients can write Controllers and receive ServerGameStates (cast into
ClientGameState, which may need to be changed).
*Participant classes have been modified to accommodate the added
behavior.
What is needed:
*Actual Controller generation is needed for the Client.  I assume this
has something to do with the ControlListener and all that, but I don't
know enough at this point.
*The appropriateness of the reading in of the ServerGameState object in
the Client class needs to be checked.  I worry that vital
ClientGameState information may be lost by the cast I've included.  An
interpretation of the ServerGameState to /update/ the ClientGameState
may be a better approach.
*The Arena class demo code will need to be changed to demonstrate the
Controller-GameState exchange instead of the String-String exchange
currently demonstrated.