Define the timeout granularity

[vlopes11]

This deviates from tendermint-style algorithms and could lead to rounds being arbitrarily skipped. This also doesn't allow for the eventuality guarantees of tendermint:

The timeouts prevent the algorithm from blocking and waiting forever for some condition to be true, ensure that processes continuously transition between rounds, and guarantee that eventually (after GST) communication between correct processes is timely and reliable so they can decide. The last role is achieved by increasing the timeouts with every new round r, i.e,timeoutX(r) = initT imeoutX +r ∗ timeoutDelta; they are reset for every new height (consensus instance).

tendermint paper

Where timeoutX could be timeoutPropose, timeoutPrevote or timeoutPrecommit.

This means we should only increment the round after properly cycling through the appropriate steps and timeouts, rather than just taking the time since the last commit and dividing it by some constant round value. Otherwise, we won't be able to increase the timeout each round.

Additionally, we may want to consider a timeout vote in the future which would allow for ddos-resistant leader selection strategies.

Originally posted by @Voxelot in https://github.com/FuelLabs/fuel-bft/pull/9#discussion_r842276758