Lint on hashing fat pointers

What it does

Lint on Arc::as_ptr(...).hash(state) and Rc::as_ptr(...).hash(state), and suggest using Arc::as_ptr(...).addr().hash(state) and Rc::as_ptr(...).addr().hash(state) respectively.

Advantage

Doing Arc::as_ptr(&Arc<dyn Trait>).hash(state) can change behavior run-by-run, as well as between debug and release mode, and is as far as I can tell almost always a bug since hashing metadata doesn't seem often useful to me.

Doing Arc::as_ptr(...).addr().hash(state) should almost always be preferrable since addr is a noop and this kind of issue is quite tricky to debug. Additionally, Arc::ptr_eq compares pointer addresses, not fat pointers.

The same should apply for Rc as well, though I haven't personally tried out whether the issue can still occur.

Drawbacks

It changes behavior, which could be unexpected for people who want to hash the pointer metadata as well. However I believe the changed behavior is what would be commonly expected from the "incorrect" code.

Example

pub struct Test(Arc<dyn Debug>);

impl Hash for Test {
    fn hash<H: Hasher>(&self, state: &mut H) {
        Arc::as_ptr(&self.0).hash(state);
    }
}

Could be written as:

pub struct Test(Arc<dyn Debug>);

impl Hash for Test {
    fn hash<H: Hasher>(&self, state: &mut H) {
        Arc::as_ptr(&self.0).addr().hash(state);
    }
}

Start from the Arc::as_ptr(...).hash(state) and Rc::as_ptr(...).hash(state) examples in the issue, and review how Rust Clippy lints provide suggestions. Done means the lint detects both cases and suggests hashing the pointer address instead, with coverage for the behavior described in the examples.