Decouple timestamp open-block-assignment/verification to Engine

[sorpaas]

Fixes #7694

The bug happens because when Parity constructs a new open block, the timestamp will be set at least one second ahead of parent timestamp. For most of the time, this works fine, and most Engine rules also require this. However, because dev chain seals a block for every transaction, it becomes a problem if one tries to send more than one transaction per second.

This PR adds two new predefined functions in Engine trait, open_block_header_timestamp and is_timestamp_valid. All other engines are unchanged except InstantSeal, where open_block_header_timestamp would not do "plus one", and is_timestamp_valid would accept it if parent timestamp equals to current one. Those replaces hard coded rules in verification mod and Header::set_timestamp_now.

This also makes the function set_timestamp_now unused. And I read a comment saying this function "kind of sucks"... So I removed it.

[debris]

neat!

[andresilva]

LGTM