Add Bitlist and Bitvector

[dankrad]

Replaces #1096 for Bitfields only

• Adding Bitvector (static length Bitfield) and Bitlist (dynamic length Bitfield)

Further fixes:

• Update simple-serialize.md with the changes that were made to the SSZ python implementation in pyspec-SSZ: lists-rework (enable static generalized indices) + fully python class based now. #1180
• Rename Bool, Bit -> boolean, bit. This means that all basic SSZ types are now lowercase (bool is not possible due to python type clash)

[JustinDrake]

We don't need this function, right?

[dankrad]

I did not change this logic at the moment because that will likely change quite a bit anyway. I think in the future, we will not need it, but I wanted to keep the old implementation alive for now.

[dankrad]

So the test that is currently failing is for the bridge to py-ssz. I think we probably can't get that to work until py-ssz has the new Bitvector and Bitlist classes. (Also, I noticed that at the moment, py-ssz does not seem to support the new max-length lists)

[protolambda]

See a5154da on the bitfield-suggestion branch.
Changed things:

• made the base class "Bitfield"
• made the metaclass consistent with the metaclass for bytes
• made it a subclass of elements-base, so that it's a list, and slicing works (slice of boolean as slice result`, can be coerced back into a bitfield
• some updates to the ssz-implementation; handle chunk count as special case for bitfields, since it's not like the other subclasses of Elements where we just assume a basic type is at least 1 byte.

Edit; ssz implementation still needs testing, we don't want every bit to be encoded as byte, and need alignment checks for non-multiple-of-8 bits in bytes.

[JustinDrake]

@protolambda: Can we avoid throwing an error with Checkpoint(previous_epoch, get_block_root(state, previous_epoch))?

>           state.current_justified_checkpoint = Checkpoint(current_epoch, get_block_root(state, current_epoch))
E           TypeError: __init__() takes 1 positional argument but 3 were given

[protolambda]

@JustinDrake Containers expect named arguments, not bare arguments. I prefer named arguments, as it enables you to shorten the names for input variables, without being less descriptive where it matters. And it enables you to leave out unused arguments. If we really want, I can add support for unnamed args, but it feels error prone (things change, and phase 1 will keep changing for a while).

[protolambda]

@dankrad @JustinDrake Can you take a look at the more explicit wording for list-limits? It's important, since it is part of consensus (max operations in a block), and merkleization with padding is a subtle combined thing, possibly not familiar to some readers.

[protolambda]

Resolving the merge conflict now

[djrtwo]

Great work @dankrad!
I have a number of minor comments but very close to merge time :)

[naterush]

Quick questions around max length merkelization

[protolambda]

Fixed the last suggestion: removed unused import for code linter