client.TraderMaker.Connect(...) method added

This method allows an external system (e.g. a network connection) to
connect to an existing trader. The existing client.TraderMaker.Make(...)
method now uses this method after it has sent the NEW_TRADER message to
the client server.

The reason we wish to be able to connect to pre-existing traders is to
allow traders with no external connection to be created and have their
state maintained as trades are processed. This allows us to easily
replay message logs on the client server and reproduce the state of
every trader reliably. It does, however, raise some questions about
scalability and robustness as each trader will be bound to a single
machine, or possibly replicated over a fix set. May need to revisit this
decision in the future.
Oustanding connects stored in map by trader id

Previously we stored all of the outstanding connect objects in a flat
list. Now they are stored in a map by trader id. This makes the code
simpler and clearer.
Trader state sent when connection is established

When a connection is established with a trader, using the connectTo(...)
method, the trader sends its current state immediately on the responses
channel.

We also removed a latent race condition where we were sending a
*msg.Message object and then using it when sending the state on the
responses channel. Now we carefully wait until the state has been sent
before we send the message on the intoSvr channel. This is something to
look out for in the future and, at the appropriate time, we should
consider moving to passing around msg.Message values, instead of
pointers.
trader now detects when orders channel is closed

Previously when the orders channel was closed, for example when a
websocket connection is closed, the trader would start receiving nil
*msg.Message objects on the orders channel and panic with a nil
dereference. Now we detect this call the disconnect(...) method on
trader.

The disconnect(...) method on trader will close the existing responses
channel and nil both the responses and orders channel on trader.
Added logging for websocket connection read
Standardised logging for svr

Simply added a local function which prints all errors, along with the
trader-id, unless the error is an io.EOF, in which case we log a useful
disconnnection message.
Now replacing message 'kind' with a string value

The kind of a message, whether it is a SELL, BUY or CANCEL etc., is
encoded as an integer. When we display it on the web-page we substitute
the int with a readable string.

This now means we are maintaining the Kind type in two separate places.
We will need to keep an eye on this in case it becomes a pain.
Now sending disconnection message to user

The response struct now contains a string field named comment. This is
now used to send an explanatory message to the user when their trader
connection is replaced by a new one.