Support limited use of generic type parameters in function signatures

[mzabaluev]

The aim is to support signatures like this:

#[test]
fn decode_from_bytes<'a, T>>() -> Result<(), <&'a [u8] as TryInto<T>>::Error>
where
    &'a [u8]: TryInto<T>,
    <&'a [u8] as TryInto<T>>::Error: std::error::Error,
{
    let v = b"Hello, world!".try_into()?;
    // ...
}

Substitution of arbitrary type parameters is fraught with breakage due to lack of hygiene, possible inferred lifetimes, lifetimes bound by a type, etc.

[mzabaluev]

I think type substitution is feasible with these conditions:

1. The instantiation type arguments have no unbound lifetimes except 'static. This is natural for a specific test function that's statically hooked into the test framework.
2. The function's signature only refers to the type parameters with simple bare paths; specifically, unqualified associated item paths are not allowed. It would require extensive replication of the language logic to determine which trait provides the associated item, and the user can easily work around this by making the path qualified, as in the example above.
3. The type paths used in the instantiation arguments do not conflict with the generic parameter names. This is the most egregious restriction, as it would require identifier hygiene to fix properly. But if this restriction remains while use of generic parameters in signatures is allowed with these rules, it will be an unhygienic wart that has no language rationale.

I haven't done an exhaustive review of the syntax, so I might be missing something.