Add multiexpand API with pipeline support, falling back to connection re-use.

@eam at the very least, WDYT about adding `multiexpand` method? If we want to add new endpoint to server in future we can switch out the implementation.

This change doesn't help that much (really we want SPDY/HTTP2 for multiplexing), but is better than nothing. I half-heartedly tried to run some benchmarks but response times are just all over the map anyways that it overshadowed any improvement with my short run times. I did confirm it was working with debug logging.

For reference, grange supports pipelining, crange doesn't. (that's just what the out-of-the-box HTTP servers are doing, I didn't change either of them.)
I'm curious how this is actually thrown. An HTTP server doesn't even need to explicitly support pipelining to "effectively" pipeline (e.g. the request gets buffered because the server doesn't even read it until the first response is processed). I think the typical danger with pipelining is that the server might choose to go away in the middle of it. In that case, it could process part of the pipeline and then include a `Connection: close` response header on one and close the connection. In this case, you have some of the requests completed. I'm guessing it's okay that this fall-back to sequential will likely repeat some of those already-completed requests?