Spawned off of #21022, #21972.

As discussed on this commit pnkfelix@8ee3c94

there are example programs (both artificial and in the wild) that have to change under the current implementation of the new scoping rules, but might not require such change if we add support for variance of type parameters: rust-lang/rfcs#281

An easy example of this, taken from the discussion on the above commit, is the following:

fn main() {
    let x = 3u8;
    let p = Option::Some(&x); // call the implicit lifetime here `&'_#1 x`
    let y = 4u8;
    constraints(p, &y); // call the implicit lifetime here `&'_#2 y`
}

fn constraints<'a> (px: Option<&'a u8>, py: &'a u8)
{
    loop  { }
}

Under the region inference constraints (regardless of which scoping rules have been adopted), '_#1 has to outlive p, while '_#2 cannot outlive y, and the call to constraints is trying to find a 'a compatible with '_#1 and '_#2.

Under the old scoping rules, p and y had the same scope, so the constraint set is satisfiable.

Under the new scoping rules, the scope of y is strictly less than that of p, so the constraint set is no longer satisfiable.

The solution adopted in #21022 is to move the binding of y up above the binding of p.

But an alternative solution is this: If RFC Issue 281 rust-lang/rfcs#281 leads to type parameter variance being implemented, then cases like this might be directly expressible (because the lifetime '_#1 will continue to outlive p, but the occurrence of p in the call to constraints would use variance to assign the scope of y (a sublifetime of '_#1) as the new lifetime embedded within the type of p.

This ticket is to mark cases that we should revisit if/when type parameter variance is implemented.