Returning XCM versioned types in XcmPaymentApi & DryRunApi

[mrshiposha]

The XcmPaymentApi::query_acceptable_payment_assets accepts the xcm_version argument to determine in what XCM format it should return the VersionedAssetIds so the client can understand. This way, the clients won't break and stop working if the chain is updated to the newer XCM version.

However, similar methods in the DryRunApi, which return the "effects" structure, don't know what the client can understand. In particular, the client needs to inspect the forwarded_xcms to dry-run the forwarded programs on other chains.

pub forwarded_xcms: Vec<(VersionedLocation, Vec<VersionedXcm<()>>)>,

The client needs to understand the first element of each tuple to convert it to the actual endpoints of the corresponding chain. It seems that DryRunApi::dry_run_call should accept the xcm_version desired by the client and return locations in that version. The DryRunApi::dry_run_xcm method could deduce the needed version by the origin_location version.

As for the second tuple element, I think it should be in the form that the other chain understands, not the client (it seems it is already the case). The client can treat it as a black box. A question, though: will PolkadotJS decode the result of the Runtime API call if it doesn't know about the new version in the VersionedXcm? This is the case when the client wasn't updated in time.

CC @franciscoaguirre

[xlc]

The V15 metadata includes the type information of runtime APIs so it is always possible to decode the returned value from a runtime API (providing the SDK supports V15 metadata https://github.com/polkadot-js/api/issues/5725).