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

TODO:
- [ ] [phoenix.js] Remove `WebSocket.[CONSTANT]` references with `Socket.states` to fully support fallback.
- [ ] [phoenix.js] Trigger close instead of error for non 200/204 response from polling
- [ ] [LongPoller] Fully unit and integration test LongPoller
- [ ] [LongPoller] Add random salt to session when encoding pid 
If we go to the HashDict approach, one of the info in the socket per channel/topic handler could be the channel module? We will only know for sure once we go to the hash dict though (and if it works).