Add intermediate representation for runtime metadata

[lexnv]

This PR adds an intermediate representation (IR) for the runtime metadata.

The IR form represents the data collected from the substrate/frame macros,
and contains all the context needed to generate multiple specific versions of the metadata
(ie, v14 for now and v15 coming soon).

This patch also exposes 2 API functions that convert the IR to appropriate versions,
depending on the selected feature flags:

• to_version: optionally convert the metadata to the specified version
• supported_versions: list of supported versions based on the feature flags

Ideally, substrate and frame-metadata would not support more than a few metadata versions at a time.

Needed to unblock paritytech/substrate#13287.
Part of: paritytech/substrate#12939

// CC: @paritytech/tools-team

[jsdw]

So the point here is that in Substrate one can spit out a single representation of the state of things, and then we can convert that information into the specific shape needed for V14, V15 etc metadata.

I like the general idea, though I guess I'm uneasy about frame-metadata itself needing to care about such a a representation. I guess I see this IR as a "runtime macro"-specific dump of various information, and then frame-metadata as the crate that defines the actual metadata shape/interface that users see.

One advantage of keeping it out of frame-metadata is that it limits any unnecessary churn here as that dump of information changes over time; the IR stuff is afterall coupled closely to what the runtime macros produce and not to the frame-metadata formats.

Another thing is that, being the "interface" crate, this is used by other crates like Subxt and so on, which would only ever care about the actual interface shape and not any of this IR stuff.

I'd be interested to know what others think about this though

[bkchr]

I'd be interested to know what others think about this though

Sounds like a reasonable approach to me!

[lexnv]

Closing this in favour of paritytech/substrate#13287