Rewrite to use private queues in each direction

This involves a fair amount of faff, including:
 - having a separate channel for 'accepting' connections

One major problem is that handshakes can become stale if they are not
fully played out, which will stall the listener, since it'll wait for
an EOF that never comes. There needs to be some detection of whether
the connection is still waiting.
Further rewriting to use streams

For that is the way and the truth, in this land.
Wait for EOF before exiting, at each end

As a corollary, when in listen mode, send EOF when the client has done
so.
Make debug output an option
Deal with 'stale' connections and ^D

When acting as a server, if our 'open' reply can't be routed we take
that to indicate that the process that sent it is no longer listening,
and move onto the next.

The connection may disappear *after* we send the open reply, in which
case we'll get stuck anyway. Still, one step at a time. I'm not keen
on sending everything with mandatory on.

(Initially I wanted to use checkQueue -- that is, a passive
queue.declare -- to check the existence of the stdout queue; however,
because it's declared as exclusive, for the same reason checking it is
useful, I can't mention it without getting a channel error! Yet
another dim bit of protocol design ..)

Responding to ^D means I have to be careful with when streams end. The
client waits for an EOF from the server before exiting, whereas the
server sends an EOF then exits. Possibly the client could do the same
as the server rather than waiting.
Add option descriptions and help option
tyop