Slot state transition with virtual skip block

[djrtwo]

A modified version of #234 that uses a "virtual" skip block instead of inserting an actual skip block into the chain. This proposal removes the "opaque-ness" of dealing with previously unknown hashes of skip blocks.

There might be minor bugs that I'll fix after some initial review/thought if we decide to go with this proposal

[hwwhww]

So the skip block only has two meaningful fields:

1. slot
2. ancestor_hashes

If skip_block is True:

• Don’t process

  1. Proposer signature
  2. Attestations
  3. PoW receipt root
  4. Special objects

• Process
  2. Some RANDAO
  3. Most per-epoch processing
  4. Verify block.state_root (state root processing, post-state-transition)

For readability, maybe in the per-slot transaction chapter, we can add a section “processing skip block” that contains all description of "the procedure of processing skip slot per-slot", and then we can jump to per-epoch chapter earlier.

[JustinDrake]

I think no skip blocks are the way forward 👍. (Technically the two approaches are probably equivalent because previous_proposal_hash can be provided at the network layer and the client can make it progress with an appropriate number of skip blocks to check it's consistent with previous_block_hash.)

Because there's no more BeaconBlock object I would call it a skip slot (as opposed to a skip block).

Feel free to close #234. (@hwwhww has made comments there which could be cherry-picked.)