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.
```
ReverseProxy uses an http.Transport.  http.Transport maintains a pool of connections, keyed to the scheme+address+proxy.  Whenever it processes a request, if it finds an idle connection in its pool matching the appropriate key based on the request, it uses that, otherwise it opens a new connection and adds it to the pool.  If a connection has been idle for too long, it gets removed from the pool.

In the case of flashlight, the connections in this pool are enproxy.Conn objects.

So in effect, yes, inbound HTTP 1.1 connections are broken up into multiple outbound HTTP 1.1 connections.  Interestingly enough, the CDNs do the exact same thing, namely maintaining a pool of connections to our backends and distributing requests via those.  This is what I mean when I say that connections in this scheme are relatively meaningless compared with LittleProxy, where connections are actually maintained end-to-end.

The exception to this, however, are HTTPS connections, which get a dedicated enproxy.Conn.  The requests that implement this enproxy.Conn actually will get split across multiple connections between flashlight and the CDN, and the CDN and our backend flashlight, but there's only a single connection out from the backend flashlight to the destination server.