Add block proposals and lookahead posting

[AnshuJalan]

This addresses issue #9.

I have added a small design nuance that I would like further discussion on under this PR.

Besides, when an epoch does not have a single preconfer in any of the slots, I advocate for falling back to a randomly selected preconfer in another situation—when the current epoch's lookahead is invalidated.

There are two reasons for this:

• When the lookahead is invalidated, how do we decide who the next preconfer/poster will be for the current epoch?
  • One approach is to leave it to a random operator to push the lookahead, but that may lead to a race condition.
  • Another option is to have the disputer push the correct lookahead, but does it make sense to add more complexity to lookahead dispute?
• Changing the lookahead for the in-flight epoch without disturbing other constraints (like allowing a future preconfer to preconf empty lookahead slots in advance) requires quite a bit of additional storage state, which seems to bloat up the contract.

[linoscope]

I advocate for falling back to a randomly selected preconfer in another situation—when the current epoch's lookahead is invalidated.

This sounds good to me, especially since the second point you raise:

Changing the lookahead for the in-flight epoch without disturbing other constraints (like allowing a future preconfer to preconf empty lookahead slots in advance) requires quite a bit of additional storage state, which seems to bloat up the contract.

The lookahead dispute will be an edge case that should only happen very rarely in practice, so it makes sense to fall back to the simplest approach.

[AnshuJalan]

Made the proposal function payable as it is a requirement of the internally called proposeBlock function in TaikoL1.