Added dispatch package

The dispatch package manages a central collection of queues (right now
chans) for coordinating data flow through the matching engine. The
intention for this design is that all logging and performance tagging
(nano tags tracking orders) is done inside the dispatcher.

There is a single queue for writing messages into the dispatcher. When
the dispatcher receives a message it logs it (if logging is switched on)
and then forwards it to the appropriate recipient.

A typical flow would look like this

Listener 	- Receives Order on network forwards to Dispatcher
Dispatcher 	- Logs Order and passes it to the Matcher
Matcher 	- Adds order to matcher state and passes ACK Response
		  (plus possible match results) to Dispatcher
Dispatcher	- Logs Response(s) and passes it to the Responder
Responder	- Sends Response(s) back to sender over the network

It is not obvious why we would introduce a single queue bottleneck into
our application. There are two reasons.

One, all filesystem access is done from a central location. If we
logged information, Orders in and Responses out from different places
in the code it would be hard to avoid lock contention for write access.

Two, since performance tagging will resolve down below millisconds it is
advantageous to use a single core to get these values. This advantage
may not hold in the future and is a bit speculative.

The success of this approach relies on two things being true. First the
incoming (submit) queue to the dispatcher must not be a bottleneck. The
dispatcher code itself must not be a bottleneck. Access to the
filesystem will almost certainly be a bottleneck but this design
isolates that and allows us to focus on alleviating it as much as
possible.