Possible deadlock when receive loops on both sides of an unbuffered connection try to send.

[zenhack]

While debugging #189, @lthibault and I realized there is another possible deadlock bug which was not triggered by his test program, but which is theoretically possible:

If two return messages are in being processed at the same time, one on each side of a connection (where both implementations are go-capnp, as opposed to some other language), each will try to send a correspdonding Finish message from within the receive loop, and it will not process any further messages until this finish has been written to the connection.

If the connection is unbuffered (e.g. net.Pipe), this could cause a deadlock, as neither side's send will complete until the other side tries to receive.

I suspect there may be other similar bugs. As a general principle, we should endeavor for the receive loop to never block, and I would be surprised if these were the only deadlock bugs that resulted from violating this general principle. (The cause of #189 itself is more complicated, but also involves blocked receive loops).

[zenhack]

At some point I'd like to audit the implementation and pin down all the places the receive loop is blocking, and see if we can eliminate them.

[zenhack]

(To clarify, obviously it is okay for the receive loop to block when waiting for a message to receive. But I think this is the only such case).