feat: allow accounts to submit multiple, partial votes

[mds1]

This is intended as a discussion, not something that will definitely be implemented.

Using arbitrary GOV token and Aave receipt token aGOV for the below.

Problem

Currently, aGOV token holders vote until X blocks before the proposal deadline, to leave time for the rolled up vote to be cast. Block numbers are used because that's how the OZ governor tracks proposals. This has a few issues:

1. It doesn't work as cleanly on L2s or chains like Avalanche where block production is not at a fixed rate. You have fewer guarantees of how much time will be enabled to cast the rollup vote.
2. Users have no guarantee their rollup vote will be cast unless they send it themselves.
3. Users have a smaller voting window when voting with aGOV compared to GOV voters.
4. Tracking proposal vote counts for an ongoing proposal lags: Expressed aGOV votes are not cast until near the deadline, so other voters have less information about existing votes, and there may be a large change once the rollup vote is cast. You can solve this with a UI/data layer that aggregates across all flexible voting contracts, but (1) that's complex, and (2) there's no guarantee those votes will all be cast.

Solution

Modify GovernorCountingFractional so accounts can vote multiple times, but cannot re-cast votes. Assuming I have 10 GOV tokens, sample UX would be:

1. Casting a single yes vote for all 10 tokens
2. Casting an initial vote of 7 yes votes and a second vote of 3 no votes
3. Casting an initial vote of 7 tokens, split into 5 yes and 2 no, a second vote of 3 tokens split into 1 yes and 2 no.
4. Casting an initial vote of 5 tokens, split into 4 yes and 1 no, a second vote of 3 tokens split into 1 yes and 2 no, a third vote of 2 tokens split into 0 yes and 2 no.

As an individual, you would never do anything except the first bullet. But this is useful for flexible voting to mitigate all of the above issues. Additionally, this does not mean you can change votes—once an initial

From an implementation perspective I don't think it should be too complicated:

• Pools such as FractionalPool no longer need CAST_VOTE_WINDOW
• GovernorCountingFractional now tracks how many tokens of a users voting weight have been used. Note that none of the above means you can change votes—once my initial vote of 7 tokens has been cast, I can only submit 3 more votes. I cannot replace/update those 7 votes (unless we want to allow that, but feels like a separate issue)

There is very likely other implementation details, and perhaps downsides, that I'm missing that need to be discussed