Enforce migrations to be standalone scripts

[kianenigma]

Follow up on the discussion here: https://github.com/paritytech/substrate/pull/10233#discussion_r749441704. Currently, we keep some migration codes in the code, and even those that we do are pretty much useless. Given this our support for historical migrations are basically near-nothing.

I propose we enforce all migrations to be self-containing henceforth. This means that they should not depend on anything from the pallet.

If they need a struct, they must duplicate that version of it in their own local scope. If they need a particular storage item, they can mimic it using generate_storage_alias.

Next to this, we are moving toward banning on_runtime_upgrade inside the pallet (https://github.com/paritytech/substrate/issues/8713). This is aligned with this issue as well. To begin with, migrations should be controlled explicitly by the top-level runtime.

Once we have all of this, I belive we can make migrations fully automated. Each migration will have a u32 id. Each pallet will have an on-chain u32 identifier, akin to the current storage version. Upon each runtime upgrade, if any migrations have been added to the repository will be executed. These migrations need to be added to some static registry.

Regardless of realizing the last statement or not, in order to for the migrations codes that we keep in substrate to have any utility, we better start by making them independent of the pallet. Some examples of this already exist (pallet-elections-phragmen).