Scenarios for runtime upgrades using referendas (root & whitelisted caller tracks)

[karolk91]

Scenarios here aim to test authorize_upgrade + apply_authorized_upgrade two-step runtime upgrade approach as its done in real-life networks through Referendum via Root track or Whitelisted Caller track

There are multiple combinations that can occur:

1. Referendum submitted using Root track or Whitelisted Caller track
2. If Whitelisted Caller track used then there is also Fellowship entity involved which approves (whitelists) the authorize_upgrade call before execution of the referendum itself. Fellowship entity resides on relay (Kusama) or collectives chain (Polkadot)
3. Implementation here is relying on set_storage calls to artificially speed-up the referendum - eg. schedule nudge_referendum calls on next block to fast forward ref state transitions, and then also scheduling the ref call itself once confirmed it got eventually approved (based on https://docs.polkadot.com/tutorials/onchain-governance/fast-track-gov-proposal/)

[github-actions]

The changes introduce new test suites for runtime upgrades via governance referenda. However, there are several copy-paste errors in the new test suite helper functions in packages/shared/src/upgrade.ts that cause them to test the wrong scenarios (self-upgrade instead of cross-chain upgrade). Additionally, there is a brittle try-catch block for resolving type definitions and a commented-out test that should be addressed.

[github-actions]

Found critical logic issues in the scheduler manipulation helper moveScheduledCallToNextBlock within packages/shared/src/upgrade.ts, including incorrect index handling for lookups and potential data loss when moving agendas. Also identified questionable usage of the test suites where AssetHub is configured as the governance chain upgrading the Relay Chain.