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.
```
> Amongst the two current strategies, there's no major advantage to buffering other than that it's required for some CDNs like Fastly. Yes it avoids the use of chunked encoding, which has a little overhead, but that's not something I'd worry about.

Right. I guess what I'm suggesting is pretty darn close to just using the buffered approach for non-HTTPS traffic, but I agree it's not a big win, as in the one case we set the Content-Length and in the other we send the last chunk. Not a big over the wire byte difference, and the servers handle them basically the same way.


> Both current strategies already maintain a single connection to the CDN (subject to the CDN closing that connection of course) per enproxy.Conn. The enproxy.Conn doesn't necessarily correspond to a single connection from the browser, but that doesn't really matter - for plain-text HTTP the httputil.ReverseProxy will open as many connections as it needs based on current traffic, and for HTTPS connections we do actually open a single enproxy.Conn per connection from browser.

Interesting. So the reverse proxy is effectively breaking apart an HTTP 1.1 connection into multiple connections, one for each request, is that correct? Or does it really base the number of connections on how much traffic it's seeing and dynamically distribute requests across those connections? 

I was assuming that it was passing those HTTP 1.1 connections through (i.e. keeping them a single connection).

I would agree it doesn't sound like a big win.