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.
```
Interesting thoughts.  Few things ...

1. 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.

2. 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.

3. The strategy that you suggest of actually matching enproxy's requests up with real requests from the browser would reduce latency a little bit by getting rid of the need to wait for the idle interval before flushing the request.  We could even go a step further and not even encapsulate the request, but rather just modify some of the headers the way that we used to, which would then save us the cost of a few HTTP headers.  The problems with ditching encapsulation are 1) we run the risk of the CDN messing up the headers in some unexpected way and 2) as we learned from the original flashlight, if we don't encapsulate we will need to provide CDN-specific strategies for modifying/stripping headers.

On the balance, I suspect that there's not much to be gained by implementing the suggested optimization for HTTP.  To test it, we could run the old version of flashlight against a test server in Singapore to see how it does.