Remove implicit numeric generics

[vezenovm]

Problem

Once #4633 is closed we will have support for explicit numeric generics. You can currently use implicit numeric generics.
Example:

struct MyStruct<S> {
    data: [Field; S],
}

This is limiting and causes duplicate definition errors when working with the new explicit numeric generics. This also is confusing for users as there are now two different ways to declare numeric generics. We should move to just using explicit numeric generics.

Happy Case

In #5155 a warning has been included when implicit generics are used and we simply do not add the generic variable to scope if there is another variable already in scope.

We should remove declare_numeric_generics and only use explicit numeric generics.

We also need to make sure to generalize the kind check inside of resolve_type_inner after #5155. Right now we just check the kind of NamedGeneric's but we should be checking the kind's of all types. The existence of implicit numeric generics complicates the more thorough kind checking introduced in #5155 as it requires us to have a much more complex implicit numeric generics system that accurately resets the kinds of implicit generics. This was deemed unnecessary as implicit numeric generics are already going to be removed in favor of the more robust explicit numeric generics system.

When checking all type kinds we can fail on this code:

    struct ValueNote {}

    trait Serialize<N> {
        fn serialize(self) -> [Field; N];
    }

    impl Serialize<1> for ValueNote {
        fn serialize(self) -> [Field; 1] {
            [self.value]
        }
    }

However, if we mark trait Serialize<let N: u32> the code will succeed as the generic on Serialize has the correct kind.

Project Impact

None

Impact Context

This will be breaking for a lot of code. That is why we have settled on a tiered approach for introducing the feature.

Workaround

None

Workaround Description

No response

Additional Context

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[TomAFrench]

I think enough time has passed that we can push forwards on this.

[TomAFrench]

@michaeljklein can you take this on?

[michaeljklein]

@TomAFrench sure