Removed packaged cbuf

This package was being kept around because it was expected it could be
reused when we came to re-evaluate the use of channels for message
passing. This will not happen for a very long time, if ever, so keeping
this code around is less valuable. Additionally the code is not very
complex and will probably prove to be wildly innapropriate when we start
exploring finely tuned queue implementations.
client/ with Client, Trader and TraderMaker types

The Client is an empty vessel used to hook into the coordinator package
to provide communication between a large number of traders and a
matching engine. The Client type is very similar to the
coordinator/client type used for testing. It contains two channels to
allow multiple Trader objects to use a single Client for communication.
The intClient channel is for sending messages to a matching engine and
the outOfClient channel is for receiving messages back from the matching
engine. When a Client is created a TraderMaker is also created linked to
that Client.

The intoClient channel also doubles for registering new traders. We use
the same channel to prevent race conditions between registration
messages and messages intended for a matching engine.

The Trader provides a simple interface for submitting trades (buy, sell
and cancel) which are then forwarded to the connected Client. Traders
are made by a TraderMaker.

A TraderMaker is created along side a Client and can be used to create
Traders which are connected to that Client
Fixed defect where duplicate ACKs were filtered

If an ACK was received twice it would be filtered by the message ticker.
This defect becomes visible in the following scenario.

1: Message 'm'  is sent by sender.
2: 'm' is received by receiver. An ACK message is created and sent back
    to sender.
2: Sender receives the first ACK.
3: Sender sends 'm' again (possibly due to some application defect)
4: 'm' is received by receiver. Although the message is de-duplicated by
    the ticker an ACK still sent back to sender.
5: Sender receives second ACK, but this ACK is deduped by the ticker and
   so Sender continues to automatically re-send 'm' waiting for the ACK.

This makes the messaging protocol too delicate and will become
overloaded if some poorly programmed application starts sending
duplicate messages. For this reason all incoming ACK messages are
allowed into the system, bypassing the ticker.

A test was added to tlisten_test.go for this scenario.