Add an intra-doc link disambiguator for fields

[camelid]

I have code like this:

struct Foo { bar: i32 }

impl Foo {
    /// Get a reference to [`Foo::bar`].
    //                            ^^^ I want this to link to the field. Currently it links to the method.
    fn bar(&self) -> i32 { self.bar }
}

This is a decently-common Rust "design pattern" where you have have a private
field but give public read-only access via a method of the same name. However,
there's no way in rustdoc currently to disambiguate between the function and the
field. Rustdoc seems to always link to the method in this case.

It would be good if we had a disambiguator for struct/enum fields: something
like field@Foo::bar. I don't think it's necessary to have a different one for
struct vs enum variant fields, but we should still decide that since intra-doc
links are now stable (and thus we can't remove things).

See the discussion on Zulip.

cc @jyn514

[camelid]

It would be nice if we had special-casing for the disambiguator so that [`field@Foo::bar`] renders as Foo.bar. That would save a lot of doing [`Foo.bar`][field@Foo::bar].

[GoldsteinE]

IMHO using [`Foo.bar`] to create a link to the field is much more intuitive than [`Foo.bar`][field@Foo::bar] and generally looks nicer. Fields can’t even be referred with ::, so it’s hard to guess this syntax.

[JarredAllen]

IMHO using [`Foo.bar`] to create a link to the field is much more intuitive than [`Foo.bar`][field@Foo::bar] and generally looks nicer. Fields can’t even be referred with ::, so it’s hard to guess this syntax.

Yeah, I second this. [`Foo::bar`] for unambiguous cases needs to stick around for backwards-compatibility, but I think [`Foo.bar`] is a better disambiguator for fields than [`field@Foo::bar`]. It matches the syntax used to access it better, and also imo it fits cleaner into the pattern of [`Foo::bar()`] and [`Foo::bar!`] disambiguators for methods and macros.