WIP.

* [ ]  Rename `TypeId` struct?

* Moves `TypeDef` into `TypeId::Custom`

* Removes `HasTypeDef` trait etc.

* Based on #36 for standardised json names

* Adds `TypeId::Collection` variant and defined `Vec<T>` and `BTreeMap<K, V>` as collections

* The `String` struct is now moved to prelude, distinct from the `Str` primitive

I will have a deeper look into the changes later.

* [ ]  Rename `TypeId` struct?

How about just Type?

* Moves `TypeDef` into `TypeId::Custom`

No, we actually want to flatten the variants of TypeDef into variants of TypeId (or Type). It is as if TypeDef distinction never happened.

* Removes `HasTypeDef` trait etc.

Yes please, and macros.

* Adds `TypeId::Collection` variant and defined `Vec<T>` and `BTreeMap<K, V>` as collections

Why?
Please elaborate.

Also we want to merge Struct and TupleStruct to Aggregate as well as ClikeEnum and Enum to Variant. The builders for each should make sure that for example either all or no fields of the new Aggregate type have names to reflect upon Struct (named fields) and TupleStruct (no fields). Same for Variant that reflects merged ClikeEnum (not nested but might have explicit tags) and Enum (potentially nested, no tags).

This way the whole type-metadata crate is more language agnostic and no longer explicitly about Rust. Instead of Aggregate and Variant we could also make it Product and Sum types. But the latter might be too theoretical.

Yes, how about just Type?

Agreed was thinking the same thing.

Why?
Please elaborate.

This is an attempt to solve the original problem of "Vec<u8>": { elems: "Vec<u8>" }". I will elaborate in the PR description once I am finished working through the other changes.

merge Struct and TupleStruct to Aggregate

In this vein we could also combine the existing TypeId::Tuple which is just an "anonymous" TupleStruct

This is an attempt to solve the original problem of "Vec<u8>": { elems: "Vec<u8>" }". I will elaborate in the PR description once I am finished working through the other changes.

Please don't try to fix this problem in this PR. I have talked to JS guys and will think about a proper solution as a follow-up.

In this vein we could also combine the existing TypeId::Tuple which is just an "anonymous" TupleStruct

Hmmm interesting idea but I am hesistant to do this since struct type definitions generally refer to library types that can have generics etc. But yeah maybe you are right. Try to experiment with pros and cons of this approach please.

Also I forgot to mention that we want to get rid of the Union type definition. It simply doesn't make sense since unions in Rust are way too specialized and cannot even stand for their own. They always need a context in which they have certain semantics.

Please don't try to fix this problem in this PR. I have talked to JS guys and will think about a proper solution as a follow-up.

I'll take it out, and potentially create a follow up PR with the same idea or similar with proper explanation. I think this also might be a proper solution. But better to separate it. Interested to hear your ideas too.

Closing in favour of paritytech/scale-info#3