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.

[area]

Yep, you're right, I think I nope'd out at the summing of the yayVotes and didn't look further when I should have.

[area]

In recognition of #928, should there be something to do with escalation on VotingBase, even if it's just a virtual function that needs to be implemented on contracts that inherit?

[area]

The implication here that this is a totally new contract, that people won't be upgrading from the old one (a viewpoint also supported by the storage changes)? In which case, this definitely needs a new identifier, and I would argue this should be a totally separate contract, with the old (not-abstracted) contract and test suite still present.

[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.