Further to #35, we should explore ways to either improve this API or even completely change approach.

The goal is to avoid the confusing API where users need to supply String as a parameter to PortableForm when decoding/deserializing.

Note that this is a constraint introduced by the requirement of integrating scale-info into substrate runtimes.

Ideas discussed with @Robbepop

• Add a crate feature which defines the type of the String at compile time.
• Remove the metadata definitions from the runtime wasm in substrate and generate it as a separate process similar to ink!. Note that this is something I will explore anyway, and if we do it we will be able to generate metadata in the std environment which could just use Strings