Just like outputthread can have processed the message
but not yet called msgput, the same is true of the
connoutthread, so we cannot check c->nmsg until
after the connoutthread has shut down gracefully.
1. Could happen that connoutthread sends c->outq a nil
just before the regular input handler sends c->outq a real message.
When the connoutthread gets the nil it will free c->outq,
leaving the real message unprocessed.
2. Could happen that the outputthread writes a message
body to the remote 9P server and then a response comes
in and then the connection gets torn down, all before the
outputthread manages to call msgput(m).
Thanks to David Swasey for identifying this scenario.
Also change yield() loop into explicit communication.
Also remove dead code involving hungup queues.
Move libfmt, libutf into subdirectories of lib9.
Add poll-based socket i/o to libthread, so that we can
avoid using multiple procs when possible, thus removing
dependence on crappy pthreads implementations.
Convert samterm, acme to the single-proc libthread.
Bring libcomplete, acme up-to-date w.r.t. Plan 9 distribution.
