Token & Hybrid Voting

[kronosapiens]

Closes #90

This PR introduces two new extensions: VotingToken.sol and VotingHybrid.sol. As expected, VotingToken implements token-based voting, while VotingHybrid implements joint reputation- and token-based voting, defined as requiring both reputation- and token-weighted votes to pass.

VotingToken

VotingToken implements similar voting logic to VotingReputation, with the material difference being that token balances are used to determine "influence", rather than domain-specific reputation balances. This difference has a number of implications:

• Every token vote must place a lock on the token. To do this, we introduce authorized functions in the colony to place locks on the token.* This function is restricted to extensions managed by ColonyNetwork.
• Token balances are not domain-specific, so VotingToken only supports root-level motions. Note that you can still hold a token vote on an issue pertaining to a domain (such as an expenditure, or to do arbitration) but the vote still "takes place" in the root.
• To simplify the implementation of VotingToken and enable code re-use between token and reputation voting, "reputation" and "token balances" have been abstracted into "influence". All voting implementations must implement a getInfluence function which is called by the base contract when tabulating votes / calculating rewards.

** Note that technically, the restriction achieves little, since there is nothing preventing a bad actor from creating a separate colony to grief holders of a token by placing arbitrary locks. As a friction, however, it should reduce the incidence of attack.

VotingHybrid

Hybrid voting is implemented as a voting contract which uses two influence values instead of one. Otherwise, it behaves very similarly to Token voting, in that motions are root-level only and involve placing locks on the tokens.

[kronosapiens]

@area I don't follow your comment about Hybrid Voting -- the vote passes if every sub-vote passes (see here).

[kronosapiens]

Following on the discussion in #product-private, we will proceed by disabling the fast-forward functionality for token & hybrid votes, on the grounds that these votes are intended to be infrequent and high-stakes, making the fast-forward functionality (say that five times fast) less important.

[kronosapiens]

This PR has been updated with the feature changes we've discussed and is ready for review. I would suggest not doing anything about external escalation until later on, once we've had a chance to discuss the functionality in some detail and think about the arguments, etc. Once I've gotten a rough approval for the PR as-is, I'll restore the original VotingReputation contract as we've discussed.