Refactor protocol for faster iterator requests (#29)

## What is the goal of this PR?

The existing protocol made a round-trip to get an iterator ID and then individual round-trips for each result.

The goal of this PR is to optimise this design to require minimal roundtrips, reducing the effect of latency on queries with many results and the concept API.

## What are the changes implemented in this PR?

* All iteration requests and responses are now separated from single-response methods, which makes their behaviour difference much clearer. `Req` and `Res`, and `Iter.Req` and `Iter.Res` are now all 1-to-1 mappings.
* Iterator requests no longer return an iterator ID upfront. Instead, they begin iterating immediately.
* Iterating no longer requires a single new request for each element. Iteration results are streamed as messages from the client to the server until the stream terminates (with a done response or...)
* Iterators can now temporarily terminate with a new `Iter.Res iteratorId` result, which gives the user an iterator ID that they can use to continue iterating with `Iter.Req iteratorId`.
* Users can specify the desired batching behaviour of any iteration request with `Iter.Req.Options`, primarily the batch size (optionally asking for all results).

Author: Adam Mitchell