* Cleanup comments related to custody
* Rename "Miscellaneous" to "Custody" in the table of contents
* Use `INITIAL_SLOT_NUMBER` instead of `0` for initial custody slots
* (typo) Fix `second_latest_custody_reseed_slot` => `penultimate_custody_reseed_slot`
* `processed_deposit_root` => `latest_deposit_root`
* `receipt_root` => `deposit_root`
* `receipt_tree` => `deposit_tree`
* Emphasize that deposits are Ethereum 1.0 deposits in text in various places
* `Eth1Deposit` => `Deposit` for consistency (Also happy sticking with `Eth1Deposit` and replacing `deposit_` with `eth1_deposit_` everywhere. This may be unnecessary since Ethereum 2.0 deposits can be distinguished with the `shard_` prefix, e.g. `ShardDeposit` and `shard_deposit`.)
* Clarify `withdrawal_credentials`.
* Clarify that multiple Ethereum 1.0 blocks can have the same deposit root.
Added `latest_vdf_outputs` in `state` initialised to an array of `ZERO_HASH` of length `LATEST_RANDAO_MIXES_LENGTH // EPOCH_LENGTH`. (There's one VDF output per epoch. The VDF input is the RANDAO mix at the epoch boundary.)
Further changes to activate VDFs (in a future phase):
* Add a new beacon "VDF output and proof" transaction, e.g. with `MAX_VDF_OUTPUT_AND_PROOF := 1`.
* Adjust the `MAX_SEED_LOOKAHEAD` constant, e.g. to `2**4 * EPOCH_LENGTH`. (The `2**4` parameter is essentially `A_max`.)
* Add a `process_vdf_output_and_proof` helper function in the per-block processing:
* Verify the VDF input hasn't already been processed (check the corresponding `state.latest_vdf_outputs` entry is not `ZERO_HASH`.)
* Verify the proof is correct, i.e. matches the VDF input and output
* Save the VDF output to `state.latest_vdf_outputs`
* In the per-epoch processing set the corresponding entry in `state.latest_vdf_outputs` to `ZERO_HASH`.
* Use a VDF output for the shuffling seed.
* Fixes parameters and makes clear that the inactivity leak is on a per-epoch basis (before the leak was technically 64 times too weak as it was calculated per-slot but applied per-epoch)
* Adds a `// 2` to the inactivity leak to compensate for it being applied twice
* Changes how it is calculated (no inactivity leak for not being part of the head, only basic leak)
* Separates out early inclusion incentives into a separate incentive component rather than being multiplicative with everything else