change INITIAL_SLOT_NUMBER to avoid underflow checks

[djrtwo]

Changed INITIAL_SLOT_NUMBER to be define as 3 * EPOCH_LENGTH to avoid a host of underflow checks/errors that needed to be fixed in state recalculations.

addresses #224

[JustinDrake]

Paging @paulhauner and @arnetheduck

[hwwhww]

Looked the spec again, it seems we didn't check if block.slot >= INITIAL_SLOT_NUMBER?

I think it enhances the correctness at a certain level; but in practice, the block, attestations are downloaded/received from the internet, so the client side still has to implement the type check upon receiving the data. That said, it seems this spec implies a validity check of that "slot number should be equal to or larger than INITIAL_SLOT_NUMBER" upon receiving block or attestation.

[djrtwo]

The genesis block at INITIAL_SLOT_NUMBER is finalized. A client can disregard any blocks that come prior to or are in forks that do not include the last finalized block.

Because of this, I don't think we need to include that extra validity condition

[hwwhww]

A client can disregard any blocks that come prior to or are in forks that do not include the last finalized block.

Yeah, that works (covered block.slot >= INITIAL_SLOT_NUMBER condition).

I think "a client can disregard any blocks that come prior to or are in forks that do not include the last finalized block" is similar to what I mean by "the client side still has to implement the type check upon receiving the data"? It's implicit here.

[djrtwo]

Closing in favor of shifting in general to additions in conditionals rather than the current subtractions.