Initialize block timestamp based on dBFT context instead of miner proposal

[AnnaShaleva]

After #49 PrepareRequest is being constructed based on the latest miner sealing proposal. It leads to the fact that header's timestamp may differ a bit from the one that dBFT would like to set in PrepareRequest from the dBFT context. Currently PrepareRequest timestamp setter do not perform any modifications in the proposed header's timestamp, ref. b6b912efff994108704ba73fffef72ae9abb98f4.

This issue is not critical for the network functioning, but ideally we'd like to have exactly those header timestamp that dBFT sets during PrepareRequest construction. This issue roughly depends on #54 and can be done only after #54 is solved.

Note: implementation of this issue may require excluding timestamp from worker seal hash calculations, so that finished sealing task may still be recognizable by worker. But again, it depends on the way how #54 will be implemented, maybe we don't even need to keep worker compatibility requirement.

[AnnaShaleva]

Should be handled carefully due to #140. There's a TIMESTAMP opcode which potentially may have the same problem as DIFFICULTY if we change the logic of block's timestamp submission from miner's to dBFT's.