Lint to detect hardcoded doc links in macro generated methods that should not be hardcoded

What it does

It is a somewhat common pattern to use macros to define identical methods on multiple types (the standard library does this with integer types).

One possible mistake might be writing the docs for one of these methods in a way that only makes sense for one of those types.

Advantage

Removes confusing docs

Drawbacks

There may be legitimate reasons to mentioning a type in this way (thus this would likely need to be a restriction lint, and additionally it should probably check that the type is not mentioned in another location in the method's signature).

Example

struct Foo;
struct Bar;

macro_rules! impl_stuff {
    ($Type:ty) => {
        impl $Type {
            /// frobs the [`Bar`]
            fn frob(&self) {}
        }
    }
}

impl_stuff!(Foo);
impl_stuff!(Bar);

Could be written as:

struct Foo;
struct Bar;

macro_rules! impl_stuff {
    ($Type:ty) => {
        impl $Type {
            #[doc = concat!("frobs the [`", $Type, "`]")]
            fn frob(&self) {}
        }
    }
}

impl_stuff!(Foo);
impl_stuff!(Bar);

Comparison with existing lints

No response

Additional Context

No response

Start from the macro example in the issue and investigate how Clippy handles documentation links in macro-generated methods. Define the proposed restriction lint's scope, including legitimate type mentions and signature references; the issue names no files or tests, so its completion criteria are not yet established.