Use custom types in data structures

[Nashatyrev]

As soon as there are strict custom types for helper functions may be it makes sense to use them appropriately for data structures members like below.

BeaconState
{
    # Misc
    'slot': Slot,
    'genesis_time': 'uint64',
    'fork': Fork,  # For versioning hard forks

    # Validator registry
    'validator_registry': [Validator],
    'validator_balances': [Gwei],
    'validator_registry_update_epoch': Epoch,

    # Randomness and committees
    'latest_randao_mixes': [Bytes32],
    'previous_shuffling_start_shard': Shard,
    'current_shuffling_start_shard': Shard,
    'previous_shuffling_epoch': Epoch,
    'current_shuffling_epoch': Epoch,
    'previous_shuffling_seed': Bytes32,
    'current_shuffling_seed': Bytes32,
...

In our Java implementation we already converted the structures members (like this) and constants (like this) to custom types (where applicable) which significantly improved readability and type safety.

[JustinDrake]

Agreed this improves readability! We can even define a Hash custom type.

[Nashatyrev]

Cool! I can take care of PR then.
We also added Time type (aka number of seconds), though it's not too widespread.
Another question: is there any means to specify the array index type, like below?

  'validator_balances': [ValidatorIndex => Gwei],
...
  'latest_block_roots': [Slot => Hash],
  'latest_index_roots': [Epoch => Hash],

[hwwhww]

I'm not sure if I like it or not. Some notes:

1. The current data structure section is defined with SSZ serialization types. I’d say let's not mix custom type and SSZ in the same section; so if we want to use custom types to describe data structure, do it fully. That said, some other types like Bitfield: bytes, Bool: bool (Turned slashed and initiated_exit into booleans #658) would need to be defined as well.
   • Then we will find that 'justification_bitfield': 'uint64' is suspicious but correct…ahhh.. (see Is justification_bitfield an integer or a bytes type? #371)
2. However, declaimed, in Python, the typing custom types are not strict. So it won’t improve type safety in programming-level (helper functions), only in readability-level.

[Nashatyrev]

1. I would consider custom types as alias types for SSZ serialization types so nothing should change from SSZ point of view.
   We currently have the following additional types:

• Hash
• Time
• Bitfield for Attesstaion
• Bitfield64 for justification_bitfield

What's left 'raw' UInt64:

• Eth1DataVote.vote_count
• Deposit.index
• ForkData.previous/current_version
• different flags

(some may be outdated or missing since we didn't yet migrate from Spec v0.1)

2. Sure I suppose the type-safety is about implementation not the spec.

[JustinDrake]

Closing in favour of #1156 :)

Sorry it too this long @Nashatyrev. Feel free to review that PR.