Consider making "built-in" complex types more strongly typed

[ascjones]

Currently builtin types like Option, Result, Range etc. are defined as normal Composite or Variant types in the prelude. One downside to this is that it requires string matching in downstream consumers in order to identify the types.

One option to make it more strongly typed would be to introduce another top level variant e.g. BuiltIn or Prelude which contains a sub enum which would cover all the possible prelude types.

This would make it easier to differentiate between user defined types and built-in scale-info types.

Related #130

[Robbepop]

We could make the path representable as builtin which is only allowed from within the scale-info crate. So user defined types cannot have a builtin path. The set of types with a builtin path must be fixed and known upfront - e.g. Option<T>, Result<T, E>, Range, ... This way we avoid another huge set of ever growing enum variants for every builtin type but third party tools have a simple and efficient way of detecting an actually builtin type and differentiating one from a user defined type.
This kinda is possible nowadays with the prelude path if we were able to stop users from defining types with such a path.

Instead of making path more complex by introducing a builtin path we could also simply use a bool flag is_builtin that defaults to false and is not serialized therefore for all non-builtin types.

[ascjones]

At the moment all those types are in the "prelude" namespace (i.e. no namespace in the path), but there is nothing at the moment to stop a custom type being constructed with an empty namespace.

Anyway I have already released 1.0 now so added this to the 2.0 milestone. It's not a showstopper but we can certainly improve the experience here.