Ensure slot number is strictly increasing

[JoshOrndorff]

This PR adds a simple storage item and validation check that ensures the slot number associated with each block is always strictly greater than the previous highest slot number in this chain.

Nimbus has always assumed this invariant to be true, but has not enforced it. In the parachain context, we are guaranteed increasing slot numbers because we use the relay chain parent number which is always strictly increasing. But in other contexts, nimbus will need to ensure this manually. (Plus nimbus should ensure it manually anyways in case the design of cumulus ever changes without warning.)

This works toward #1 and #3

[4meta5]

we are guaranteed increasing slot numbers because we use the relay chain parent number which is always strictly increasing

asynchronous backing will remove this guarantee such that there may be multiple parachain blocks for a single relay chain parent block

[4meta5]

We can change > to >= when asynchronous backing is included

[4meta5]

Thanks @JoshOrndorff !

[4meta5]

Suggested change

	T::CanAuthor::can_author(&author, &T::SlotBeacon::slot()),
	T::CanAuthor::can_author(&author, &slot),

[4meta5]

just missed this, not sure how much better it is

[notlesh]

We should bump the weight returned by on_initialize() to reflect the extra read/write here.

[JoshOrndorff]

Rob gives some options for how to address asynchronous backing in paritytech/polkadot#3779 (comment)

I had also considered a notion of slot that is derived from both the relay block number and parachain block number, maybe k * relay_height + para_height % k

Maybe that's similar to his idea # 3