Replace home-grown network IO stack with tornado for katcp server

Doing so lets us use the tried and tested goodness of tornado. Also gives us some async coroutine goodies for 'free'. This is a big change, and I would like several people to review it.

Since most of our codebase is not async-aware, the DeviceServer can be used in three modes, depending on the options passed to the set_concurrency_options() method.

1. Fully async mode. All code must be aware of the fact that all IO calls need to be made from the ioloop thread, and request handlers must *never* block. Currently won't work because of SamplingReactor working in a separate thread.
2. Thread safe IO, but request handlers must still be non-blocking. Performance overhead due to thread safety management.

Upcoming Work
=============

1. Make the DeviceServer  handle_message function support coroutine handlers, or anything returning a future. Should not be too hard.
2. Implement SamplingReactor to use ioloop and not own separate event loop. Needed to support Fully async mode. Might also clean up sampling to support a generic callback that takes the sensor reading rather than the KATCP formatted message, in a backwards compatible way.
3. Make client classes use tornado. Should be able to re-use the read-loop from the server here.