ThreadMessageHandler: replace MilliSleep() with condition variable

I'm hoping to get some feedback on this.  It was mentioned by @gmaxwell that there is a 100ms sleep inside ThreadMessageHandler() which can delay the receiving and sending of network messages.  By replacing this with a semaphore, it can hopefully improve block propagation times.

I haven't experienced any connections stalling with this patch, so it seems to work, and the ThreadMessageHandler() loop executed about 10 times per second on average when I tested with 8 peers.

There is still a lot of overhead since each execution of the loop does a scan of all nodes to check for new messages to send/receive, which I believe will happen every time there is a post() done on the semaphore. But, I haven't noticed any additional CPU load with this patch. 

I am yet to test how this effects block propagation.  Does anyone have a testing environment where you can roll out patches and test their effect on block latency?
Due to using relative durations there's a slight window for a race condition here:
- `boost::posix_time::microsec_clock::universal_time()` called the first time in the while() clause and returns a value `< alarm`
- `boost::posix_time::microsec_clock::universal_time()` called the second time in the subtraction returns a value `> alarm`
In this case either a negative value would be passed to timed_wait, or an integer overflow would happen resulting in a very long wait.

BTW: there is also a time_wait that takes an [absolute system time](http://www.boost.org/doc/libs/1_56_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref.condition_variable.timed_wait), would that be useful here?