Improve beacon proposer selection logic

[djrtwo]

Substantive changes:

1. sample proposer from the full set of active validators (as opposed to just the first committee)
2. make proposer slashing per-slot (as opposed to per-epoch)

Advantages of the new proposer logic:

• improved liveness: The beacon chain can progress with just one validator (as opposed to SLOTS_PER_EPOCHS, an unintended design flaw). Improved liveness with low validator count may be useful for testing, fuzzing, and private consortium beacon chains.
• reduced complexity: Avoid calling get_committee_count, get_start_shard and get_crosslink_committee. Reduce get_beacon_proposer_index line count by 20% (from 15 lines to 12 lines).
• improved fairness: Ensure that the probability of being selected as a proposer is proportional to the effective balance. The current design gradually breaks fairness as the number of validators decreases.
• more natural design: Block proposing is natively per-slot, not per-epoch. Block proposing is orthogonal from the notion of committees, and per-slot slashing is more natural than per-epoch slashing.
• phase 1 reuse: The compute_proposer_index can be reused in phase 1 (see Revamp 1_shard-data-chains.md #1383).