Governance E2E tests: simulate passing referendum's lifecycle

[x3c41a]

Goal

The goal of the test is to simulate the successful flow of a referendum on a Treasury.spend of some foreign asset:

1. submit referendum withtreasury.spend call - link
2. place decision deposit - link
   • without a decision deposit, the referendum will time out
3. modify referendum to simulate the passing of the preparation period - link
   • see 5. below for what it means to modify the referendum
4. vote on the referendum - link
5. re-inject the referendum's data, but with an older submission datum to mimic a referendum that's been confirming for a while (and voting data that passes accordingly). This last part is harder:
   • need to build the approval/support curves from the track's data,
   • find the necessary approval/support values for the given elapsed confirmation period,
   • and change the ref's tally accordingly,
6. inject a call to the scheduler, for the next block, for nudge_referendum

@rockbmb to confirm flow correctness ^
(✅)

Why can't we wait for the passing of a referendum's relevant periods?

Waiting for the confirmation period to elapse in tests is not viable - the smallest of all tracks is 10 minutes (100 blocks), in the Small Tipper and Whitelisted caller tracks.
Similar reasoning applies to the preparation and decision periods.

In other words, even the fastest track will introduce significant overhead in test execution.
The goal of this issue is to track the implementation of this specific flow.

Other flows like cancellation/killing/timing out can be tested independently of this "happy" path.

P.S.
Reference PR: #306

[rockbmb]

This is recent, and very relevant: https://docs.polkadot.com/tutorials/onchain-governance/fast-track-gov-proposal/#