Support Compact types about scale-info

[Robbepop]

Let me quickly concretize what those 3 different approaches could look like:

Examples

Following are 3 scale-info encoded JSON example showing a composite type:

pub struct Foo(Compact<i32>);

Using a built-in scale-info compact type:

{
    "strings": [
        "Foo", # ID 1
    ],
    "types": [
        { # ID 1
            "compact": 2
        },
        { # ID 2
            "primitive": "i32"
        },
        { # ID 3
            "composite": {
                "path": [ 1 ],
                "fields": [
                    { "type": 1 }
                ]
            }
        }
    ]
}

Using a built-in flag for compact types:

{
    "strings": [
        "Foo", # ID 1
    ],
    "types": [
        { # ID 1
            "primitive": "i32"
        },
        { # ID 2
            "composite": {
                "path": [ 1 ],
                "fields": [
                    { "type": 1, "compact": true }
                ]
            }
        }
    ]
}

Using a special custom type for compact types: (Taking the one from scale library)

{
    "strings": [
        "scale",   # ID 1
        "Compact", # ID 2
        "T",       # ID 3
        "Foo",     # ID 4
    ],
    "types": [
        { # ID 1
            "primitive": "i32"
        },
        { # ID 2
            "composite": {
                "path": [ 1, 2 ],
                "params": [ 3 ],
                "fields": [
                    {
                        "type": {
                            "parameter": 3
                        }
                    }
                ]
            }
        },
        { # ID 3
            "composite": {
                "path": [ 4 ],
                "fields": [
                    {
                        "type": {
                            "generic": {
                                "type": 2,
                                "params": [ 1 ],
                            }
                        }
                    }
                ]
            }
        }
    ]
}

[Robbepop]

I am leaning towards the last example even though it seems to be the most convoluted solution because it plays nice with our other proposal for generics support (#6) and does not introduce yet another concept for the protocol but uses what is already there. Also due to the design of the generics proposal there will be at most one Compact type definition per metadata so it won't be as convoluted at scale.