netwk/MsgStore -> msg/msgutil/Set

This is the last piece being moved into msgutil/.

msgutil/Set is now a custom set implementation implementing

Add(*msg.Message) 	- Adds a message to the set
Remove(*msg.Message) 	- Removes a message from the set
Do(func (*msg.Message)) - Performs some action over the set

Identity of a message in the set is Kind/TraderId/TradeId

Small changes include

randomMsgs() -> randomUniqueMsgs() Which generates a slice of 100 unique
*msgs.Message (a test is used to ensure uniqeness)
Message Routes simplified to ACK, APP and SHUTDOWN

This change was made so that we could reuse the coordinator to build
trading clients. Previously we had routes like MATCHER_RESPONSE which
would be routed from the matching engine to the responder (and onto the
network). But a trading client won't be sending MATCHER_RESPONSE routed
messages onto the network, it will be sending ORDER routed messages. We
collapsed ORDER and MATCHER_RESPONSE routed messages into a single APP
route.

APP:

An APP route can be produced by an application, and head for the network
For example, a matching engine emits messages like PARTIAL and FULL,
while a trading client emits messages like BUY and SELL.

An APP route can also come in from the network destined for an
application. For example a matching engine receives messages like BUY
and SELL, while a trading client receives messages like PARTIAL and
FULL.

We added a direction flag to indicate whether or not an APP routed
message was coming IN from the network or going OUT from an application.
The lifecycle of an APP message is as follows.

1: An application creates an OUT-APP message and it is passed on to the
	responder and onto the network
2: The responder receives an OUT-APP message and switches it to an
	IN-APP just before sending
3: The listener receives an IN-APP message and it is passed on to the
	application

ACK:

Used to acknowledge an APP message that has been received

Both the trading client and matching engine maintain lists of unacked
APP messages. An ACK clears the ACKed message from this list. This route
also requires the IN, OUT direction distinction. And has the following
lifecycle.

1: The listener receives an IN-APP message and generates an OUT-ACK
	message for it. The listener passes the OUT-ACK message on to
	the responder.
2: The responder receives an OUT-ACK message and switches it to an
	IN-ACK just before sending
3: The listener receives and IN-ACK message and it is passed on to the
	responder
3: The responder receives an IN-ACK message and removes the
	corresponding message from its list of unacked messages

SHUTDOWN:

Indicates that the system should shut itself down gracefully. This
message is not acked. The lifecycle of a SHUTDOWN message is as follows.

1: The listener receives a IN-SHUTDOWN message and passes it on to the
	dispatcher. After the message is sent the listener shuts itself
	down.
2: The dispatcher receives an IN-SHUTDOWN message and passes it on to
	the application.
3: The application receives an IN-SHUTDOWN message and sends an
	OUT-SHUTDOWN message to the dispatcher. After the message is
	sent the application shuts itself down.
4: The dispatcher receives an OUT-SHUTDOWN message and passes it on to
	the responder. After the message is sent the dispatcher shuts
	itself down.
5: The responder receives an OUT-SHUTDOWN message and shuts itself down.