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?
Doing this a few times is probably to blame https://github.com/phoenixframework/phoenix/blob/master/test/phoenix/integration/channel_transports_test.exs#L198

Basically, I set a small LP window, and sleep past it's timeout to test this case. There may be a better way, but I had to bump the window to 100ms or we occasionally get failures since pinging the running router case be delayed depending on sys load. Better solutions for testing the LP window?