Tracking issue for future-incompatibility lint `uncovered_param_in_projection`

This is a tracking issue for the lint uncovered_param_in_projection which was added in #117164.

The lint detects a violation of one of Rust's orphan rules for foreign trait implementations that concerns the use of type parameters inside trait associated type paths ("projections") whose output may not be a local type that is mistakenly considered to "cover" said parameters which is unsound and which will be rejected by a future version of the compiler.

Originally reported in #99554 (kept open) and tracked in rust-lang/types-team#104.

Example

// dependency.rs

#![crate_type = "lib"]

pub trait Trait<T, U> {}

// dependent.rs

trait Identity {
    type Output;
}

impl<T> Identity for T {
    type Output = T;
}

struct Local;

impl<T> dependency::Trait<Local, T> for <T as Identity>::Output {}

fn main() {}

This will produce:

warning[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Local`)
  --> dependent.rs:11:6
   |
11 | impl<T> dependency::Trait<Local, T> for <T as Identity>::Output {}
   |      ^ type parameter `T` must be covered by another type when it appears before the first local type (`Local`)
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #124559 <https://github.com/rust-lang/rust/issues/124559>
   = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local, and no uncovered type parameters appear before that first local type
   = note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last
   = note: `#[warn(uncovered_param_in_projection)]` on by default

Begin with the lint introduction in #117164 and the example in this issue, then review the unresolved context in #99554 and rust-lang/types-team#104. This tracking issue does not define a concrete change or acceptance tests, so the intended compiler work and definition of done must first be established with the relevant team.