Added optional support for request streaming, closes getlantern/lantern#1767

It's not clear how much of an improvement this will be.  Before and after test results below:

### Before
```bash
➜  ox.to.a.cart  boom -allow-insecure -n 1000 -c 10 -q 100 -x http://localhost:10080 https://www.google.com/humans.txt
1000 / 1000 Boooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00 % 

Summary:
  Total:	62.8833 secs.
  Slowest:	5.4758 secs.
  Fastest:	0.5246 secs.
  Average:	0.6260 secs.
  Requests/sec:	15.9025

Status code distribution:
  [200]	1000 responses

Response time histogram:
  0.525 [1]	|
  1.020 [962]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  1.515 [26]	|∎
  2.010 [1]	|
  2.505 [0]	|
  3.000 [0]	|
  3.495 [0]	|
  3.990 [6]	|
  4.486 [1]	|
  4.981 [1]	|
  5.476 [2]	|

Latency distribution:
  10% in 0.5348 secs.
  25% in 0.5430 secs.
  50% in 0.5544 secs.
  75% in 0.5701 secs.
  90% in 0.6613 secs.
  95% in 0.8907 secs.
  99% in 3.6958 secs.
```

### After
```bash
➜  ox.to.a.cart  boom -allow-insecure -n 1000 -c 10 -q 100 -x http://localhost:10080 https://www.google.com/humans.txt
1000 / 1000 Boooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00 % 

Summary:
  Total:	61.7948 secs.
  Slowest:	4.8525 secs.
  Fastest:	0.5229 secs.
  Average:	0.6149 secs.
  Requests/sec:	16.1826

Status code distribution:
  [200]	1000 responses

Response time histogram:
  0.523 [1]	|
  0.956 [960]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  1.389 [27]	|∎
  1.822 [1]	|
  2.255 [1]	|
  2.688 [2]	|
  3.121 [0]	|
  3.554 [3]	|
  3.987 [3]	|
  4.420 [1]	|
  4.852 [1]	|

Latency distribution:
  10% in 0.5348 secs.
  25% in 0.5428 secs.
  50% in 0.5528 secs.
  75% in 0.5701 secs.
  90% in 0.6596 secs.
  95% in 0.8202 secs.
  99% in 2.3905 secs.
```
OK cool. Quick question as a thought exercise as much as anything else: It seems like request streaming clearly makes sense for CONNECT requests where we have no idea when the data will end. I would argue it also makes sense for POST requests because it's much more likely there will be a lot of data in the request. Beyond that, I suppose it also makes sense for HTTP 1.1 in theory *except* for the fact that I believe pretty much no clients use pipelining. With that being the case, it seems like in practice we'll hit our flush timeout prior to the second request coming through in most cases (since it'll wait for the response).

So I guess I'm wondering if there's room for optimization of the strategy we use based on the requests from the client in addition to what the server side (CloudFlare etc) supports. 

YouTube would be an interesting test of this. I believe YouTube issues a series of plain text HTTP requests for the video file itself. In those cases, we should know the complete size of the request and should be able to just set that in our own content-length header encapsulating the data to YouTube. In that scenario, I would think we could keep a single connection open to CloudFlare that issues multiple HTTP requests, each one encapsulating the underlying browser's HTTP request for a chunk of the video, which would really be an entirely new strategy that's not buffering and that's not streaming.

What's incorrect about the above if anything?