Lint on `as_deref` from `&&T` to `&&T` or `&T` to `&T`, to catch people thinking "deref" dereferences

I recently watched a Rust coding livestream, and someone had an Option<&&'static str> (obtained from HashMap::keys() on a HashMap with &'static str keys). They wanted to get an Option<&'static str>.

They initially tried reaching for as_deref(), because it had deref in it so they assumed it dereferenced. This seems like a likely trap for new developers.

I think we should flag cases where someone calls as_deref on a type that's statically known to contain a reference (e.g. Option<&T> or Option<&&T>, or likewise for Result) and gets back exactly the same type, particularly if there's a type error saying that they needed the dereferenced type. The lint could tell them they might want .copied() or .cloned() (depending on whether the type implements Copy or Clone).

Simple example:

fn main() {
    let mut m: HashMap<&'static str, &'static str> = HashMap::new();
    m.insert("hello", "world");
    let k = m.keys().next();
    let dereferenced: Option<&'static str> = k.as_deref();
    println!("{dereferenced:?}");
}

The issue names no implementation files or tests; start by locating Rust's lint implementation and existing lint tests for Option and Result methods. Use the examples in the issue to check reference-containing types, and consider the proposed copied or cloned guidance as part of the completed diagnostic.