Transport adapter contract and Long-Polling

I've refactored our WebSocket-only Channels into a "Transport Contract" to support any kind of transport protocol or `%Phoenix.Socket.Message{}` serialization format. This PR contains working WebSocket and Long-Polling transports, as well as an updated `phoenix.coffee/js` that includes long polling fallback. Instead of ripping up the current javascript client, I defined a `LongPoller` class that acts as a `window.WebSocket` shim. The long polling is automatically fallen back to if WebSocket's aren't available, and can be configured as an option, i.e.: `new Phoenix.Socket("/ws", transport: Phoenix.LongPoller)`. 

The current approach for the LongPoller on the server is to store the binary_to_term'd poller process in the conn's session and resume it for each poll. Messages are buffered by the `LongPoller.Server` until the client repolls and explicitly `ack`'s messages. The LongPoller controller also mounts itself at `/ws/poll` transparently. This will change when we tackle the `channel` macro options, something like `channel "rooms", RoomChannel, via: [LongPoller: [at: ...]]`. For now, I've left this aspect for later after we finalize the Transports.

The long polling still needs to be throughougly tested, and some docs need expanded, I appreciate any and all feedback. Thanks!

// @josevalim @scrogson @jeregrine @ericmj
> Btw, I think we should change how Phoenix.Socket works. Instead of keeping one Socket will all data and storing channels and assigns and what not, what if the transport keeps a hash dict of Phoenix.Socket with {channel, topic} as key and a Phoenix.Socket struct as value? This should help us remove the need for get_assign too, for example. What do you think?

This could work, but we would be placing more work on each transport. For example, a transport would need to know whether or not a join event was successful and throw away the socket if it wasn't. Whereas today, the multiplex socket just falls through `Transport.dispatch` and the Transport module updates the socket's authorized channel state. So to go this route we'd have to shift some responsibility down to all transports. Also, both the WebSocket and LongPoller transports multiplex the channels, so a single `Socket{}` nicely falls in line with this abstraction. Other than the `get_assign` api, are there other reasons to prefer the HashDict approach?