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
`%Message{}` protocol is confusing. Can you rephrase without using the struct notation or the word protocol (to not confuse with Elixir protocols)? :)