feat: better XCM fee management

[ntn-x2]

Fixes https://github.com/KILTprotocol/ticket/issues/2566.

This PR changes the way XCM fees are handled for DIP. Before, the provider parachain sovereign account on the consumer chain was paying for the XCM fees, while now it is the sovereign account of the user that triggered the operation on the provider chain, to also pay for the fees on the receiver chain in whatever asset specified in the extrinsic. With XCM v3, it's not possible for a parachain to charge an interior location (e.g., with a DescendOrigin instruction), hence a new barrier and a new origin converter have been introduced, which are supposed to be used together to implement the feeing model DIP has envisioned.

Relevant changes

Reworked XcmRouterIdentityDispatcher

The XcmRouterIdentityDispatcher type used to be part of the pallet-dip-provider pallet. Because it is really specific to KILT, it has been moved into the kilt-dip-support crate.
Additionally, the router now packages the DIP XCM program with the following instructions:

1. ExpectOrigin with the provider parachain origin, making sure the same XCM message cannot be sent by regular users via the XCM pallet.
2. DescendOrigin with a new AccountId32 representing the dispatcher account ID on the provider chain.
3. WithdrawAsset with the MultiAsset specified in the commit_identity extrinsic in the pallet-dip-provider pallet
4. BuyExecution with the max Weight specified in the commit_identity extrinsic in the pallet-dip-provider pallet
5. Transact with OriginKind::Native and the same weight limit as above
6. RefundSurplus
7. DepositAsset with any remaining assets in the holding registry back to the dispatcher's account on the consumer chain

In the demo runtimes and tests, the Account32Hash location converter has been used to convert the account ID information coming from the X2 junction containing the sibling provider parachain and the disptacher account.

Configurable origin for the pallet_dip_provider::commit_identity extrinsic

The CommitOrigin origin was already configurable, but now its Success result is required to implement the SubmitterInfo trait, which returns the AccountId of the tx submitter, so that the information can be used to compose the XCM message that will be sent to destination (specifically it is included in the DescendOrigin and DepositAsset instructions).
The trait has been implemented for the AccountId32 type, which is returned by the EnsureSigned origin check (which could be used for tests), and for the DidRawOrigin type, which is returned by the EnsureDidOrigin origin check (which has been used in the demo runtimes).

The AllowParachainProviderAsSubaccount barrier

For DIP to implement the feeing model devised here, where the user pays for the fees on both chain, a new barrier + origin converter must be integrated into the XCM configuration.
The AllowParachainProviderAsSubaccount barrier verifies that 1. the origin of the XCM is a parachain with an ID that is returned by the ProviderParaId generic type, and 2. the order of the instructions in the XCM program matches exactly what is expected in the DIP flow. If either the origin or the set of instructions is different, the barrier will return an error.
To extend existing barrier, there are two additional types: OkOrElseCheckForParachainProvider which tries to match the incoming XCM message against the new AllowParachainProviderAsSubaccount barrier if none of the previous barriers have succeeded (explicit approval), and ErrOrElseCheckForParachainProvider which tries to match the XCM message against the new barrier only if none of the previous barriers have failed (explicit rejection).

The AccountIdJunctionAsParachain origin converter

Since there is no way to convert an X2 junction of parachain + sub-account, the AccountIdJunctionAsParachain does just that. It takes the X2 junction of a sibling parachain + sub-account, if the parachain matches the ID given by the ProviderParaId type, and converts it into a ParachainOrigin.

The origin converter and the barrier are meant to be used together, otherwise configuring only one or the other opens the way to security issues on the consumer chain!

[enddynayn]

type OriginConverter = SovereignSignedViaLocation<(ForeignChainAliasAccount), RuntimeOrigin>;

What are the cons of using this type of configuration above?
Since DescentOrigin is modifying and extending the interior with the account. Can ForeignChainAliasAccount be used to convert the origin to a signed origin?

The consumer can filter out any calls and only allow the call function to be executed via XCM.

[ntn-x2]

The pallet expects a parachain origin, hence using SovereignSignedViaLocation won't work, unfrotunately.

[enddynayn]

Can this be accomplished with this?

type Barrier = WithComputedOrigin<(AllowTopLevelPaidExecutionFrom<DerivativeCustomerLocations>);

[ntn-x2]

As we discussed, the design at the time of this comment was flawed. I have now added a ExpectOrigin instruction early on (d683a3f). For now, this is a sufficiently good approach, which means that the WithComputedOrigin barrier would not let the call through, which is not what we want. Also the AllowTopLevelPaidExecutionFrom would fail. There is no way around using the OkOrElseCheckForParachainProvider barrier provided here. If some barrier must explicitly fail, the ErrOrElseCheckForParachainProvider should be used.