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:
- [x] [phoenix.js] Remove `WebSocket.[CONSTANT]` references with `Socket.states` to fully support fallback.
- [x] [phoenix.js] Trigger close instead of error for non 200/204 response from polling
- [x] [phoenix.js] Only send heartbeat for WebSocket transport
- [x] [LongPoller] Fully unit and integration test LongPoller
- [x] [LongPoller] Add random salt to session when encoding pid 
- [x] [LongPoller] Add Server to application supervisor for clean shutdowns
- [x] [Socket] Deprecate `get_assign`
- [x] [Router] Do not allow `channel` to be used within scopes
- [x] [Router] Do not pass through normal pipeline for ws/longpoll requests. Add special `:socket` pipeline?
We could reduce the window but the key is to make the test async. Another
idea is, if we move to the publisher proposal, we could start a new
publisher only for testing in a particular case, guaranteeing we could test
it in an async way.

-- 


*José Valimwww.plataformatec.com.br
<http://www.plataformatec.com.br/>Founder and Lead Developer*