Remove or fix message receipts to reflect tipset execution

At present, each block header contains a merklized list of messages defining the block's state transitions, and parallel list of their receipts indicating success or failure (that's not captured in the state tree itself). Receipts exist primarily to be able to provide merkle inclusion proofs of message execution to light clients. However, receipts in the current construction are not useful.

*Background*
There is also a state root CID. In other blockchains, the state root and receipts define the result of executing the block's messages. However, in Filecoin, the unit of chain progress is a tipset, not a single block. The state root defining the state after a block's messages is useless if the block was not the first in a tipset. Nodes generally need to re-execute all the messages in a tipset to discover the post-tipset state, and this isn't directly reflected in consensus data structures. Issue #505 changes the state root field to refer to the state root of the parent tipset, rather than of the block itself. This is something that all blocks in a tipset should agree on, and means that in accepting a block, nodes are agreeing that the parent tipset's state matches the CID.

*Receipts*
Receipts have the same problem. The receipts in a block are useless because message success depends on the prior state and thus the block's position in a tipset. A merkle inclusion proof of a succesful message execution doesn't mean anything, because in proper tipset order the message may have failed. Thus a light client would be required to re-execute all a tipset's messages to discover if any one truly succeeded. In light of this, the receipts are not providing any utility. It's particularly confounding when writing chain debug and inspection tools that the receipts provide misleading information sometimes.

Rather than discard them, a positive alternative might be to follow the state root CID: move the receipts for a collection of messages to the child blocks. A block would then provide the (CID of a merkle tree of) receipts for the parent tipset's message executions, rather than its own. This would involve matching the de-duplication logic that skips the same message appearing in peer blocks.

It will indeed be inconvenient that a block's message receipts are not available in the same block, but such is the cost of the multi-leader election scheme. It's more convenient than providing incorrect data and requiring recomputation, as in the current case.

cc @whyrusleeping

Start by reading issue #505 and the current block-header and receipt definitions in the specification. Determine whether receipts should be removed or moved to child blocks, including how parent-tipset execution and message de-duplication are represented. Done means the specification has one resolved receipt model that is consistent with tipset execution and light-client proofs.

Written by the indexing model from the issue text.