implement Foundation hardfork

This hardfork adds a subsidy of 30,000 SC per block. Actually, the subsidy is only distributed every 4320 blocks, so it would be more accurate to call it a subsidy of 129.6 MS per month. In addition, an initial subsidy of approximately 1.57 GS will be distributed immediately upon activation. The activation height is 293210, which is expected to fall around 3:30 PM EST on January 1, 2021.

Each subsidy payout creates a siacoin output. Like miner payouts, the outputs have a maturity delay of 144 blocks. (Unsure whether this necessary.) The outputs are sent to the "primary Foundation address," which is a special value tracked in the consensus set. They can then be spent like any other output.

(Side note: Subsidy outputs need to have IDs that are guaranteed to be distinct. I have chosen to calculate the ID by hashing the block ID with the "foundation" specifier. There is at most one subsidy per block, so we don't need to use an index, like we do for other output IDs.)

The primary Foundation address is a normal address that can receive coins, but its unlock conditions also have the power to set a new address, i.e. to determine the recipient of future subsidies. This works as follows. Any transaction can contain an ArbitraryData payload that encodes a new subsidy address. When consensus sees such a transaction, it will look for a transaction signature that covers the ArbitraryData payload. If such a signature exists, and corresponds to the current address (i.e. UnlockHash), then the change is accepted. Otherwise, the transaction is considered invalid and will be rejected.

(Side note: by "corresponds to" we mean "has a ParentID matching one of the transaction's SiacoinInputs whose UnlockConditions have an UnlockHash matching the current primary address." Basically, transaction signatures must be associated with an input or a file contract, so in order to submit an address change, the primary or failsafe address will need to spend an output that it controls. This approach has the huge benefit of allowing us to reuse all the existing transaction validation code, rather than implementing new signing/verification code specific to this hardfork.)

As the word "primary" implies, the consensus set actually tracks two Foundation addresses: the second is the "failsafe Foundation address." Subsidies are never sent to this address, but it still has the "update" power of the primary address -- and updates can update both addresses. In practice, the failsafe address will be subject to a timelock, preventing it from being used unless the primary address does not update the Foundation addresses within a reasonable timeframe.

(Side note: the failsafe address cannot retroactively gain ownership of subsidy outputs that were previously sent to the primary address. It can only determine the recipient of future subsidies.)

(Discussion point: should consensus enforce a particular minimum timelock for the failsafe address?)

(Discussion point: what if both addresses are accidentally set to uncontrolled addresses, e.g. the void address? This would make it impossible to recover any future subsidies except via hardfork. Is this acceptable, or should consensus revert to the initial addresses if the current addresses have not changed in, say, 6 months?)

Initial values for the primary and failsafe addresses will be hard-coded into the types package. The exact UnlockConditions of these address is yet to be determined, but we expect that the primary address will be a multisig address requiring signatures from at least myself and Eddie, while the failsafe address will likely be just David's key with a timelock occurring sometime after the activation height (3 months?). As a matter of general policy, the Foundation will publish the UnlockConditions for all new addresses prior to submitting the corresponding ArbitraryData transactions.

(Discussion point: should the ArbitraryData encode the UnlockConditions rather than the UnlockHashes?)

I'll add tests once we're in agreement regarding the implementation.