It's not really possible to change these values in a running client
without recreating the connection, and I suspect users will rarely want
to do that.

Passing options in function parameters makes it hard to add more
options later. Pass them in a struct instead.

This changes how we handle batch responses in order to be able to react to situations
where the server does not provide a response for every request batch element.

For some weird reason, when writing the original client implementation, I worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests [A, B, C], the server could respond with [A B C] but
also with [A B] [C] or even [A] [B] [C] and it wouldn't make a difference to the client.

So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to all requests in the batch, the client
would eventually just time out.

With the addition of batch limits into the server, I anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.

In JSON-RPC, only method calls with a non-null "id" can be responded to. Since batches can
contain non-call messages or notifications, the best effort thing we can do to report an
error with the batch itself is the first method call message.

I think adding these limits might break people's setups, so best
to avoid configuring them by default in package rpc.