Testing patch with Travis

This patch prevents the occasional failure of the unbind test on Travis. The problem was a race condition so it did not fail every time. This failure can be confirmed by running Travis on the current master branch with the unbind code in it.

The failure would usually happen with this stack.
  at null._ioevents (/home/travis/build/f34rdotcom/zeromq.node/lib/index.js:231:22)
  at Socket._flush (/home/travis/build/f34rdotcom/zeromq.node/lib/index.js:461:23)

It would also sometimes fail inside of zmq library as an assertion in mailbox.cpp or signaler.cpp

I have run several builds and so far the problem is gone. If one were to force a Travis build on the master branch it will fail after running it as few as 3 times. You are welcome to do this to confirm the bug I am describing exists as a sanity check.

 I have seen another race condition failure in test.socket.messages.lateconnect.js but one I do not think is related or as serious. I feel it is related to an insufficiently long timer in the test but it would be good to confirm this just in case by testing this patch in another branch and fixing the timer then running Travis 10 times to confirm it passes every time. Then merge this and fix the timer in a another patch to keep it separate and clean.

After having merged this, I suddenly have one reservation...

Can you explain what use-case would cause this to happen? And if it does, should we not re-flush on nextTick or something? If a flush unexpectedly interrupts with messages in our queue, how do we get it to resume?