feat: Traits methods - default and override

[yordanmadzhunkov]

#Description #2568
In this PR we introduce the following progress of implementation of traits:

• Trait supports Self as type parameter or return type
• Trait can have an default implementation that will execute if not override by the struct
• Trait can have an empty implementation which forces the struct to provide one
• Structs can implement traits and override the default implementation

Remove unnecessary checks:

• type of trait implementation doesn't have to be struct
• Remove the premature checks (from def collector), that should be done at a later phase:

Name resolution/Type checking:

• Trait function parameters (should be done later, because the current code cannot deal correctly with e.g. type aliases)
• function return type (same reason as the above)
• Check for duplicate implementations for the same Trait and Type (this check should work even for empty traits!)
• Other ( see tests in this PR)

Successful examples:

Self should typecheck properly

struct Foo {
    x: Field
}

trait Asd {
    fn asd() -> Self;
}

impl Asd for Foo {
   
    fn asd() -> Self {
        Foo{x: 100}
    }
}

fn main() {
    assert(Foo::asd().x == 100);

trait_default_implementation

trait Default {
    fn default(x: Field, y: Field) -> Self;
    fn method2(x: Field) -> Field {
	x
    }
}

struct Foo {
    bar: Field,
    array: [Field; 2],
}

impl Default for Foo {
    fn default(x: Field,y: Field) -> Self {
        Self { bar: x, array: [x,y] }
    }
}

fn main(x: Field) {
    let first = Foo::method2(x);
    assert(first == x);
}

trait_override_implementation

trait Default {
    fn default(x: Field, y: Field) -> Self;
    fn method2(x: Field) -> Field {
	x
    }
}

struct Foo {
    bar: Field,
    array: [Field; 2],
}

impl Default for Foo {
    fn default(x: Field,y: Field) -> Self {
        Self { bar: x, array: [x,y] }
    }
    fn method2(x: Field) -> Field {	
        x * 3    
    }
}

fn main(x: Field) {
    let first = Foo::method2(x);
    assert(first == 3 * x);
}

PR Checklist*

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

[yordanmadzhunkov]

@jfecher I know it's a big PR, but I hope you like it :)

[jfecher]

Can you split this into several PRs? It looks like this implements a lot of functionality so it makes it more difficult to judge what any change in particular is meant to implement. I think generally having an "other" category on a PR is a good indicator it can be split up.

Trait function parameters (should be done later, because the current code cannot deal correctly with e.g. type aliases)
function return type (same reason as the above)

We should do these type checks in the type checker when these changes are split into another PR. As you mentioned, the check would be more accurate this way, and I think it'd be easier to understand if the type checking was done during the type checking pass.

[yordanmadzhunkov]

First part -> #2585