fix: allowing accessing associated constants via Self::...

[asterite]

Description

Problem

Part of #7812
Part of #8096

Summary

This PR only solves two very specific cases.

Self::N inside a trait

This now compiles fine:

trait Trait {
    let N: u32;

    fn foo() -> u32 {
        Self::N
    }
}

For this, if we find Self::N while being inside a trait, we search for an associated constant. If we find one, that's the type of the expression. The value of the expression doesn't matter (I used zero) because trait methods never produce code, only trait impl methods.

Self::N inside a trait impl

This now compiles fine:

pub trait Trait {
    let N: u32;

    fn foo() -> u32;
}

impl Trait for i32 {
    let N: u32 = 10;

    fn foo() -> u32 {
        Self::N
    }
}

For this, if we find Self::N while being inside a trait impl, we search for an associated constant. If we find one and it has a constant value, we use that value.

What still doesn't work?

The other way to access an associated constant is in code like this:

pub trait Trait {
    let N: u32;
}

fn foo<T>(t: T) where T: Trait -> u32 {
  T::N
}

This case is trickier because even though we can find the associated type, we don't know it's value and I think we have to defer that until monomorphization... but we don't have anything to represent that, yet.

Another thing that doesn't work is the Self::N case inside a trait impl where N is an associated constant without a constant value. For example:

pub trait Trait {
    let N: u32;

    fn foo() -> u32;
}

struct Foo<let M: u32> {}

impl<let M: u32> Trait for Foo<M> {
    let N: u32 = M;

    fn foo() -> u32 {
        Self::N
    }
}

Here, like in the previous case, we can only know the value of N during monomorphization.

---

I still think this PR might be worth on its own because the logic to solve at least the last case would be around the new code, except that we need something new to represent it. And then, the two cases implemented here cover a lot of use cases, probably the most common ones.

Additional Context

1. I noticed that Type::Constant holds a FieldElement, but I'm thinking it should probably hold a SignedField.
2. Together with this PR I included a couple of nargo expand fixes regarding associated constants. I needed those for the new tests, but in the end the new tests fail for a different reason... but some of the existing ignored tests could be unignored.

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.

[asterite]

I created #8417 as an incomplete follow-up PR to show how this could be implemented for the general case. I think we need a new DefinitionKind for this. Right now that definition is pushed when we need it, but we probably want to push one definition for each trait impl associated constant and store those IDs somewhere, to later retrieve them.

But... given that I'm not too familiar with definition IDs I'd prefer to do that as a follow-up PR, if that approach would be correct.

[TomAFrench]

Forgot to hit approve on this.