tcp proxy

Hi @cortesi,

I think the tcp_proxy branch is at a good state now and ready for extended testing and/or merging. Here's the current status:
- [x] all test cases pass. :bowtie: 
- [x] both mitmproxy and mitmdump work with no observed bugs so far.
- [ ] no full test coverage
- [x] add functionality to change the destination server when intercepting flows. 
- [ ] when merging, `.travis.yml` needs to be corrected to point to pathod/netlib master again.
- [ ] when merging, the hardcoded tcp-proxying for echo.websockets.org should be removed in `ConnectionHandler.establish_ssl`.

Things that should be done, but probably not within this PR:
- [ ] We have import statement kong-fu on some places (protocol, proxy, flow). This largely comes from the fact that we already have circular imports and currently cheat by using absolute imports in `libmproxy.flow` and `libmproxy.proxy` (both import each other). This "cheat" doesn't work with submodules. We need to split up `libmproxy.proxy` and move a few other things. I did that earlier today but concluded that it would make this PR even more confusing and let it rest untils this is merged.
- [ ] Integration of actual tcp pass-through. How can a user specify which flows should be passed through as-is?
- [ ] Introduction of proper log levels. There are a ton of debug statements in the event log right now.
- [ ] Properly indicate what is host and what is destination. This is especially important for a scenario where we transparently proxify connections to an upstream HTTP proxy. (We currently show the real destination only in flow details -> server connection)
- [ ] the requestcount attribute has been removed from clientconnection. Introducing it again should not be an issue, although the notion of "requests" is blurry when it comes to WebSockets/tcp proxying. a) is it still useful to implement this again? b) do we want to have it for the server connection, the client connection, or both?