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.