Update xcm-format with v3 Instructions and Registers

[CrackTheCode016]

In an effort to sync, update, and expand the documentation around XCM in the Polkadot Wiki, I propose adding the newly added instructions and registers.

Most of the definitions for the instructions came from the XCM v3 commit code in the Polkadot repo.

Instructions Added:

• ExpectAsset
• ExpectError
• ExpectOrigin
• QueryPallet
• ExpectPallet
• ReportTransactStatus
• ClearTransactStatus
• LockAsset
• UnlockAsset
• NoteUnlockable
• RequestUnlock

Registers Added:

• Transact Status
• Topic

TODO

• MultiLocation
• Junction
  • GeneralKey
  • network fields
• MultiAsset/WildMultiAsset
• max_assets removal
• NetworkId
• BodyId/BodyPart
• Concept of UniversalLocation (for the GlobalConsensus Junction)
• Errors
• Go through XCMv3 PR and ensure that all changes are reflected in the spec.

[CrackTheCode016]

Thank you for catching that!! Let me know if there is anything else you think would be wise to include/changed.

[KiChjang]

For reference, the XCM v3 PR is here: paritytech/polkadot#4097, make sure that every new feature mentioned in the description there is reflected on this PR.

[franciscoaguirre]

Took a dive on the XCM v3 PR and diffed it here to add what was missing

Thank you for keeping the standard up-to-date with the code 🎉

[gavofyork]

Junction also changed more than this diff would imply: GeneralKey and all items which contained a network field also changed.

[vstam1]

@gavofyork Currently we describe most of the errors of the xcvm instructions as fallible or infallible. Do we want to change these error descriptions to the actual errors mentioned in the 8 The types of error in XCM section based on the implementation in the xcm-executor?

[CrackTheCode016]

Maybe not relevant for this PR, but would including hyperlinks to the xcm code in the Polkadot repo be interesting? I feel it would bring the spec more cohesion.

i.e., to specific instructions, or interfaces like XcmContext etc

[gavofyork]

@gavofyork Currently we describe most of the errors of the xcvm instructions as fallible or infallible. Do we want to change these error descriptions to the actual errors mentioned in the 8 The types of error in XCM section based on the implementation in the xcm-executor?

Yes - that could be helpful.

[gavofyork]

Maybe not relevant for this PR, but would including hyperlinks to the xcm code in the Polkadot repo be interesting? I feel it would bring the spec more cohesion.

i.e., to specific instructions, or interfaces like XcmContext etc

Sounds sensible.

[franciscoaguirre]

Left some comments on error types

[KiChjang]

This is not a good explanation, because naturally people will ask why we don't simply just use WithdrawAsset to do the job. And I don't believe it is true that any fees are eligible to be withdrawn -- only a select few instructions do this.

[vstam1]

This better?

[franciscoaguirre]

This looks like it's good to go 🚀