fix: implicitly added named generics are equal between each other

[asterite]

Description

Problem

Resolves #8177

Summary

In a code like this:

trait Bar {
    let N: Field;
}

impl Bar for Field {
    let N: Field = 42;
}

trait Foo {
    fn foo<B>(b: B) where B: Bar; 
}

impl Foo for Field{
    fn foo<B>(_: B) where B: Bar {} 
}

in the past, the compiler would fail to compile the above just because B: Bar would error saying that it's missing N from Bar's generics (that is, Bar<N = ...>). So in #7026 this was now allowed, and N was added implicitly as an unbound named generic.

When comparing where clauses, these are compared by equality (after binding substitution). The issue was that the implicitly added named generic in the first foo ended up with a type variable that's different than the one used for the second foo. Then, they aren't equal.

What's done in this PR, and I don't know if it's the correct way to solve this, was to mark these implicitly added named generics as such. Then, two unbound implicitly added named generics are considered equal, regardless of their type variable ID. For this I extracted a new NamedGeneric type instead of adding another argument to NamedGeneric(..., /* implicit /* bool) for clarity.

Additional Context

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[jfecher]

Must it be the same though?
We issue implicit NamedGenerics for associated types so this seems like it'd consider the generics from two separate associated types as equal.

[asterite]

Good point.

Originally I fixed this issue in a different way: when comparing a method where clause in a impl against its trait, I removed all implicit generics from the comparison (there's an equality comparison somewhere there). But then I thought I could also fix it by changing the equality... maybe I should have done the former?