epoch processing before block processing

[djrtwo]

• Move epoch processing before block processing (resolves Put per-slot processing after per-epoch processing #267 (comment)). Epoch transitions now happen at the beginning of an epoch before any blocks are processed from the new epoch.
• This resolves some issues with the shuffling available in state (get_shard_committees_at_slot out of range #409, get_shards_and_committees_for_slot for future slots #92, shard_committees_at_slots missing when processing previous epoch attestations #352) by ensuring epoch shuffling is updated before blocks are processed. Also changed the bounds of get_crosslink_committees_at_slot to be based upon the current_ and previous_epoch_calculation_slot and to allow for accessing shufflings arbitrarily in the future.

Note: get_crosslink_committees_at_slot can access shufflings arbitrarily in the future, but this is not guaranteed to remain stable if a state transition changes the shuffling between state.slot and the future slot (validator registry change, or power of 2 reshuffling).

Note: The per-slot transition line "Set state.validator_registry[get_beacon_proposer_index(state, state.slot)].randao_layers += 1" is still broken at the state transition epochs because the shuffling is not yet updated at this point, but I'm leaving it in because it is very likely to be removed after our discussion about removing the hash-onion entirely.

[djrtwo]

EDIT: ready for review

[vbuterin]

I'm pretty sure this is wrong, and state_epoch_slot is correct. The current_epoch_calculation_slot is the slot the data from which is used to calculate the current shuffling, which could be prior to the current slot.

[djrtwo]

Right and if it is prior, we fall through to the else and use the current_ seed, calc slot, etc.

I think this is essentially doing to same thing but more explicitly uses the slots we stored in state and I think is clearer.

The future slots is not generally safe so I'll add the restriction back in.

[djrtwo]

closing in favor of #492