Girazoki xcm max ump weight and transact info migration

[girazoki]

What does it do?

Attempt to perform an migration on the TransactInfo storage item. I had to modify the migrations pallet to accept a trait that is implemented for tuples, as this migration should only be applied to moonbase and moonriver runtimes

In particular, the TransactInfo is changed in the following ways:

• A max transact weight is added, so that we can prevent transactors from stalling the queue in the dest chain. This was previously hardcoded in the runtime, so now we make it accessible and changeable in a storage item
• fee_per_byte, base_weight and metadata_size are removed because those parameters only make sense when executing local transacitons in the relay, not transactions through xcm. For xcm, only the fee_per_weight is accounted. This has been confirmed in our Alphanet by Lido, where we have set to 0 all the non-relevant parameters and everything has been working so far.
• fee_per_weight has been changed to fee_per_second, to better reflect cases (like Kusama) in which the fee per weight unit is lower than one.

What important points reviewers should know?

Is there something left for follow-up PRs?

What alternative implementations were considered?

Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?

What value does it bring to the blockchain users?

[librelois]

@girazoki did you test the migration with try-runtime?

[girazoki]

Yes, but I will try one more time before merging because I changed the fee_per_Second

[notlesh]

LGTM, although I think this may not be the end of integer resolution problems in this code. I'm opening an internal ticket to review this later.