Message batching for performance

[bemasc]

Initial implementation in:
#269

Time-constant-free message batching requires (?) adding 'ack' messages, so that we can tell when there are too many outstanding queued messages and wait until some of them are cleared before adding more. At very high CPU load, we expect a reduction in the number of messages sent overall, because slow acks will result in batching.

Curiously, the initial implementation shows reduced throughput in uproxy-churn when only allowing a single outstanding message, but allowing up to 3 outstanding messages shows a small improvement (~10%) over baseline. More investigation might be appropriate, to confirm that this implementation is behaving as expected.