Consider changing the relationship between time windows

[pasqu4le]

Clarification and motivation

Currently, as per the spec, each proposal has 3 relevant timestamps

1. a creation time, corresponding to when it is submitted
2. a voting time, when voting starts, set on submission to begin some vote_delay time after the creation time
3. an expiration time, when it is concluded, set on submission to occur some expire_time time after the creation time

This is however a bit awkward because someone could submit their proposal with an expire_time smaller than their vote_delay, which would cause a proposal to expire before voting is allowed.

We have some choices on how to handle this:

1. check for expire_time to be smaller than vote_delay when the proposal is submitted, fail otherwise
2. make the expiration time start some expire_time time after the voting time
3. ignore this potential problem in the contract, have it be handled in the off-chain app instead

Acceptance criteria

A decision is taken and if necessary the specification and the smart contract are updated accordingly.