Resolve Self::AssocType as ctor when it's an associated type

[nyurik]

Vibe code alert: I manually did all sorts of cleanup for this, but the core of the try_associated_type_constructor was vibe-coded, and despite being "seemingly" correct, it might be completely bogus due to my lack of full internals understanding... than again, not many ppl on this planet have "full" understanding of the rust compiler's code :)

When path resolution fails for a value like Self::Associated or Self::Err(42), check whether we're inside an impl and the name is an associated type that resolves to a struct (unit or tuple). If so, treat the path as that struct's constructor. This only happens if all other type resolutions have failed. BTW, @adwinwhite suggested that this might be unfixable due to backwards compat in #120871 (comment) -- so my approach could be totally wrong.

• Fixes no associated item found for struct in the current scope while it exists #71054 (unit struct: Self::Associated)
• Fixes Unable to find assoc type when using tuple create syntax Self::AssocType(...) #120871 (tuple struct: Self::Err(42))

Add try_associated_type_constructor() in FnCtxt and use it from resolve_ty_and_res_fully_qualified_call on NoMatch. Extend to support both CtorKind::Const and CtorKind::Fn.

Tests: issue-71054.rs (unit + brace form), issue-120871.rs (FromStr tuple ctor). Convert associated-type-call.rs and invalid-ctor.rs to check-pass and remove their .stderr/.fixed.

?r @petrochenkov

[workingjubilee]

We ask that you understand the code that you wrote and are able to argue, persuasively, for its correctness. Your PR description does not explain why.

[adwinwhite]

To elaborate my comment a bit:

trait Trait {
    type Tuple;
    // macros might generate unconventional names like this.
    const Tuple: isize;
}

We may have an associated const of the same name in the value space.
So registering associated types to value space unconditionally would be a breaking change.

[petrochenkov]

Technically this needs to go through the language team, but I'm skeptical about the change.
We have general rules about item namespaces, and here we randomly break them with an ad hoc rule for one specific case.