beginning an actual client-side engine using javascript.
Merge branch 'master' of github.com:biffbyrd/doppelgamer into doppelclient
removes test.coffee; I've decided I'm not so interested in developing with a language delimited by *white-spaces*
Playing around with javascript functional programming and added the skeleton of a client engine in doppelclient.js. It still does not display any graphics, but it can communicate with the server
Adds `Arrived` behavior for Rooms and implements a basic JS graphic driver (#20)

First, the Room needs to be able to tell the Player what he can see. For now, when the Player sends the `Arrived` command, the Room sends back a list of its children. The Player can then talk to each of them directly to get details. This is simply a temporary implementation. Later, we will use a more Event-driven model of moving into Rooms.

For each of the Room's children, the Player sends his ConnectionService a `create` command. The JavaScript client receives the command and acts according to the command type. In this case, `create` means he should create an object on the `view`. At the moment, the client can respond to `create`, `move`, and `quit` commands.

BUG: possible race condition: When we first start the server and point the browser to it, the `create` command and the subsequent `move` commands work just fine. When I hit `Q` and quit, the server reacts just fine and cleans up resources. When I reload the page, however, I think the Player actor sends the `create` command too quickly, and it hits the browser before it's ready. Consequently, we never see the `create` command, only a bunch of `move` commands. How should we fix this? Should the browser tell the server when it's ready? Or maybe the system should be able to work knowing that some commands will be lost in the network. Either way, it's clear there needs to be more communication.
Baking a cake with ConnectionServices (#28)

This change attempts to modularize several layers of behavior for a ConnectionService. We now have a PlayConnection that implements the sending and closing behavior. We also have a BufferingConnection and ActorConnection that can be mixed in. It's a good example of the cake pattern at work.

This refactor completely breaks the Application module's WebSocket function. It expects to get an Enumeration back in a Future, and right now that Enumeration is burried in an Actor.
Update ConnectionModule.scala
Makes it more clear that we are mutating the count
Update ConnectionModule.scala
reworks the way the App, Player, and ConnectionService talk to each other. Implements Retry functionality (still untested) in the PlayActorConnection
moved the JSON parsing logic into the Application layer so that the Player object doesn't have to worry about it. Also recoded getCommand() to use the Play JSON lib
(fixes #28) Implements the new retry actor connection and wires everything together, which required a bit of refactoring in the App, Connection, and Player modules.