Improve handling of the generic baggage fields

[vstakhov]

This PR addresses issue paritytech/orchestra#6 and allows orchestra proc-macros to deal with the generics in baggage fields.

• Support of a single or multiple Gen<T>, Gen<Gen<T>>
• Check and test complex containers HashMap<Gen<T>, Gen<U>>
• Think about lifetimes - not relevant in this case, as subsystems must be static
• Think about const generic parameters - not needed (yet), support can be added if any need arises

[drahnr]

Looks very good! Thank you

[drahnr]

This swallows somerrors, which we shouldn't swallow but expose as part of the return type

[vstakhov]

The GenericArgument enum looks the following:

pub enum GenericArgument {
        /// A lifetime argument.
        Lifetime(Lifetime),
        /// A type argument.
        Type(Type),
        /// A binding (equality constraint) on an associated type: the `Item =
        /// u8` in `Iterator<Item = u8>`.
        Binding(Binding),
        /// An associated type bound: `Iterator<Item: Display>`.
        Constraint(Constraint),
        /// A const expression. Must be inside of a block.
        ///
        /// NOTE: Identity expressions are represented as Type arguments, as
        /// they are indistinguishable syntactically.
        Const(Expr),
    }

Lifetimes are irrelevant - we can emit error on that, but it will be also emitted during compilation, as lifetimes are not efficiently supported. Binding is more interesting here, as there could be something like Item = T where T is indeed a generic. Constraint can also have generic inside. Probably, it is not a bad option just to throw an error there as it will be a compile error afterwards.

[vstakhov]

Well, adding strict checks has revealed that we have no real support of anything but paths, for example tuples. It is bad and requires some more changes...

[vstakhov]

To clarify, the existing implementation supports Vec<(type1, type2)> but not (type1, type2).

[vstakhov]

With this approach, baggage type is now Type not Path that allows to put more syntax elements into baggage, such as tuples, functors and so on. Not all types could be flattened so far, but this could be extended if needed. Apparently, with Path restriction it was impossible to use such types in the builder's setters as well.

[eskimor]

bot merge

[paritytech-processbot]

Waiting for commit status.