backport pallet-xcm::transfer_assets_using_type_and_then() (#3695)

[acatangiu]

Add transfer_assets_using_type_and_then() for transferring assets from
local chain to destination chain using explicit XCM transfer types:

• TransferType::LocalReserve: transfer assets to sovereign account of destination chain and forward a notification XCM to dest to mint and deposit reserve-based assets to beneficiary.
• TransferType::DestinationReserve: burn local assets and forward a notification to dest chain to withdraw the reserve assets from this chain's sovereign account and deposit them to beneficiary.
• TransferType::RemoteReserve(reserve): burn local assets, forward XCM to reserve chain to move reserves from this chain's SA to dest chain's SA, and forward another XCM to dest to mint and deposit reserve-based assets to beneficiary. Typically the remote reserve is Asset Hub.
• TransferType::Teleport: burn local assets and forward XCM to dest chain to mint/teleport assets and deposit them to beneficiary.

By default, an asset's reserve is its origin chain. But sometimes we may want to explicitly use another chain as reserve (as long as allowed by runtime IsReserve filter).

This is very helpful for transferring assets with multiple configured reserves (such as Asset Hub ForeignAssets), when the transfer strictly depends on the used reserve.

E.g. For transferring Foreign Assets over a bridge, Asset Hub must be used as the reserve location.

ERC20-tokenX is registered on AssetHub as a ForeignAsset by the Polkadot<>Ethereum bridge (Snowbridge). Its asset_id is something like (parents:2, (GlobalConsensus(Ethereum), Address(tokenX_contract))). Its original reserve is Ethereum (only we can't use Ethereum as a reserve in local transfers); but, since tokenX is also registered on AssetHub as a ForeignAsset, we can use AssetHub as a reserve.

With this PR we can transfer tokenX from ParaA to ParaB while using AssetHub as a reserve.

AssetA created on ParaA but also registered as foreign asset on Asset Hub. Can use AssetHub as a reserve.

And all of the above can be done while still controlling transfer type for fees so mixing assets in same transfer is supported.

Provides the caller with the ability to specify custom XCM that be executed on dest chain as the last step of the transfer, thus allowing custom usecases for the transferred assets. E.g. some are used/swapped/etc there, while some are sent further to yet another chain.

This allows usecases such as:
https://forum.polkadot.network/t/managing-sas-on-multiple-reserve-chains-for-same-asset/7538/4

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6202979

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/managing-sas-on-multiple-reserve-chains-for-same-asset/7538/7