The current implementation of `wait'` first retrieves the socket's
file descriptor and uses GHC's `threadWaitRead` and `threadWaitWrite`
to wait. Then it checks the 0MQ socket events if writing or reading
could be done in a non-blocking way.
AFAICS the file descriptor should only be polled for read events, as it
most likely isn't the actual FD where data is sent through. This aligns
with what api.zeromq.org states:
"[...] the ØMQ library shall signal any pending events on the socket
in an edge-triggered fashion by making the file descriptor become
ready for reading." 
The behaviour described in #55 is caused by using `threadWaitWrite` on
this FD which immediately returns, but asking for `ZMQ_POLLOUT` events
is answered negatively as no clients have connected. Hence the loop is
restarted ad infinitum.
A related issue is the edge-triggered fashion in which the FD is
signaled. Currently we might wait longer than necessary for subsequent
messages as we always wait on the file descriptor first which would be
correct for level triggering.
This commit changes the behaviour in that we always inspect the 0MQ
socket events first. If they match with what has been requested we
directly continue writing or reading. Only if this test fails do we wait
with `threadWaitRead` for the underlying FD to become ready.