IATs: Decide if we want to hard-error on inherent projections if the path in question may just as well refer to an enum variant

For forward compatibility with hypothetical (enum) variant types, we currently reject trait associated type projections if the path in question may just as well refer to enum variants. By "reject" I mean we issue the deny-by-default lint ambiguous_associated_items (#57644) for backward compatibility:

enum Type { Variant }

trait Trait { type Variant; fn scope(); }

impl Trait for Type {
    type Variant = ();

    fn scope() {
        let _: Self::Variant; //~ ERROR ambiguous associated item
    }
}

For the IAT analogue, we currently don't emit this lint / any error:

//@ check-pass
#![feature(inherent_associated_types)]

enum Type { Variant }

impl Type {
    type Variant = ();

    fn scope() {
        let _: Self::Variant;
    }
}

The question is: Should we?

Note that for trait associated type paths, we have syntax to disambiguate them: Fully-qualified paths: <$Type as $Trait>::$PathSeg while for inherent associated type paths there's none.

(There's the obvious question of whether we will ever actually support some form of variant types or if pattern types will supersede them but that's a T-lang question I guess and therefore we should probably better be safe than sorry and just hard-reject these cases as ambiguous.)

Start by comparing the trait associated type behavior and the inherent associated type example in the issue, focusing on the ambiguous_associated_items lint and the lack of fully qualified syntax for inherent paths. Determine whether the inherent case should be rejected for forward compatibility; done means a documented language-team decision and corresponding coverage for the shown examples.