Readded CommMaker to client/ pkg

Previously we had removed the client.CommMaker and allowed the client.C
type to make new client.Comm objects. However, this forces us to pass
around the client.C object to anyone who wishes to create new
client.Comm objects. They are then presented with a confusing pair of
methods, Run() and NewComm(), where NewComm() is perfectly legal and
calling Run() will probably cause the client to stop working properly.
The CommMaker removes this hazard and provides clarity to the user.
Now checking errors on user-submitted messages

Errors validating user-submitted BUY/SELL/CANCEL orders are now checked
and will result in a "CLIENT_REJECTED" type being returned to the
web-browser.
FULL/PARTIAL messages processed by one method

The fullOutstanding and partialOutstanding methods have been combined
into one matchOutstanding method in user.go.
Moved the Guid functions into new ints/ package

The old functions have been renamed:

MkGuid(...) -> Combine(...)
GetTraderId() -> High32()
getTradeId() -> Low32()
receivedMessage.Type -> FromClient, Accepted

Previously the recievedMessage struct contained a field called Type.
This was a string field (although with a fancy typedef) with three
possible values: "ACCEPTED_CLIENT", "REJECTED_CLIENT" and "FROM_SERVER".
The two different pieces of information encoded have been split out into
the separate boolean fields FromClient and Accepted.

It is worth noting that if FromClient is false (i.e. the message came
from the server) then Accepted is always true.
stockManager introduced

We now track the number and kind of stocks that a user owns. The stock
manager was introduced to track this information and also to prevent a
user from selling stock that he/she does not own.

The stock manager maintains two distinct sets of information. A set of
'held' stocks which the user owns. A set of 'to-sell' stocks, which the
owner owns and are currently part of an un-matched/cancelled sell order.

The process for selling stock:

When a sell order is submitted
1: Check that the user has the number of stock he/she wishes to sell.
2: Deduct that number of stocks from the 'held' total and add it to the
   'to-sell' total.

When a sell order is matched (PARTIAL or FULL)
1: Deduct the number of stocks in the match from the 'to-sell' total.

When a sell order is cancelled
1: Deduct that number of stocks from the 'to-sell' total and return it
   to the 'held' total.

The process for buying stock:

When a buy order is matched (PARTIAL or FULL)
1: Add the number of stocks bought to the 'held' total.

Currently a user is given a small number of stocks to begin trading
with.
balanceManager introduced

Imitating the stockManager we have moved all the cash balance logic into
a type called balanceManager.

The balanceManager maintains two pieces of information. The 'current'
balance and the 'available' balance. The 'current' balance represents the
total amount of cash the user owns. The 'available' balance represents
the cash which is not tied up in open BUY orders. This is to prevent a
user from submitting more BUY orders than he/she can afford.

NB: The total value of an order or match is (price * amount).

The process for selling a stock:

When a sell order is matched (PARTIAL or FULl)
1: Add the total value of the match to both the 'current' and
   'available' balances

The process for buying a stock:

When a buy order is submitted
1: Ensure that the total value of the order is less than or equal to the
   user's 'available' balance
2: Deduct the total value of the order from the user's 'available'
   balance

When a buy order is matched (PARTIAL or FULL)
1: Deduct the total value of the order from the user's 'current'
   balance. Note that we have already reduced the 'available' balance
   when the buy was submitted.

When a buy order is cancelled
1: Add the total value of the order back to the user's 'available'
   balance.
Price is now uint64, rather than int64

This prevents us from ever accidentally introducing a negative price.
Previously we were using negative prices to represent matched buys.

The rationale behind this was that it would allow clients to easily
identify whether a match was for a buy or a sell by testing the sign of
the price. In practice we need to find the order that has been matched
anyway, so we can determine whether the matched order was a buy or a
sell from the originating order directly.