Only use BigNumbers for math

[tinybike]

The UI presently uses BigNumbers for a variety of things where they are unhelpful or inappropriate (e.g., market IDs are sometimes BigNumbers, sometimes hex strings). I think we should minimize BigNumber use for the following reasons:

1. BigNumbers must be serialized to be sent over the wire. This is inefficient and adds another thing that can break to an already complex scheme. The middleware should be lean, mean, and not bogged down by unnecessary data transformations.
2. BigNumbers cannot be passed to the Decimal constructor, which we use for involved mathematical calculations.
3. BigNumbers do not by default print in an easily-readable form. For example, naively passing an array of BigNumbers to console.log will give you a screenful of entries that look like { [String: '-5.4917889867110182400182506605075850537547051241964636844222872410989124212006e+76'] s: -1, e: 76, c: [Object] }.
4. BigNumbers are incompatible with the clone library, which we use for fast object deep-cloning. Cloned BigNumbers become non-BigNumber objects, with the same field names, which has led to several incredibly hard-to-diagnose bugs.

Inappropriate use of BigNumbers has led to a number of utterly avoidable bugs during the alpha. To prevent any more unforced errors, I'd like to propose the following rules for BigNumber use:

• BigNumbers should only be used when performing mathematical operations.
• Labels -- addresses, market IDs, event IDs, etc. -- should always be stored as hex strings, not BigNumbers.
• Integers should be stored as JavaScript numbers, not BigNumbers.
• Decimals should be stored as stringified numbers, not BigNumbers.

Please post any questions about or objections to these rules here.

[tinybike]

Fixed in 59f966ae8b6d24f221fec1ec166e75a53216429e.