BIP8: clarify timeoutheight behaviour and requirements

When lockinontimeout is true, we don't transition directly from STARTED
to LOCKED_IN, so don't imply that we do.

If startheight or timeoutheight are not on a retarget boundary, they
behave as if they had been rounded up to the next retarget boundary,
so to keep things simple, require them to be at a boundary.

If timeoutheight is less than two retarget periods later than startheight,
behaviour when lockinontimeout is true (one retarget period of STARTED,
one of MUST_SIGNAL, one of LOCKED_IN, then ACTIVE) will not match
behaviour when lockinontimeout is false (one retarget period of STARTED,
then either LOCKED_IN or FAILED), so disallow that as well.

bip-0008.mediawiki

@@ -53,6 +53,8 @@ The following guidelines are suggested for selecting these parameters for a soft
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
 timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
 
+'''startheight''' and '''timeoutheight''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
+
 ===States===
 
 With each block and soft fork, we associate a deployment state. The possible states are:
@@ -88,7 +90,7 @@ For flexibility, during the LOCKED_IN phase only, this rule does NOT require the
 
 <img src="bip-0008/states.png" align="middle"></img>
 
-During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeoutheight''' is reached.
+Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
 
 The genesis block has state DEFINED for each deployment, by definition.