Create max array and list limit

[stringhandler]

Fixes #398

A type annotation with a huge array size or list bound made the compiler allocate a Vec proportional to that size with no cap. Because StructuralType::from() lowers every type during ordinary type unification, merely naming such a type was enough to trigger a multi-gigabyte allocation or a capacity-overflow panic, giving anything that compiles .simf a trivial DoS.

This adds MAX_ARRAY_SIZE and MAX_LIST_BOUND (both 2^16) and rejects anything larger during parsing, before any lowering happens. The cap is applied at all four places a size reaches a type: the [T; N] and List<T, N> annotations, plus array_fold::<f, N> and fold::<f, N>. A literal that overflows usize is now reported as too large rather than silently becoming 0. Tests cover each site and assert the reproduction no longer panics.

[Sahilgill24]

This PR also solves another bug similiar to the one it is fixing where a large array size being declared was looked at by the compiler as [u8;0]
ex.

  fn main() {
      let x: [u8; 99999999999999999999999999] = [];  
      let y: [u8; 0] = x;
  }

This code used to get compiled without any error code, but now with this PR it is also fixed :) .

[apoelstra]

These limits are far too low. If we must have them they should be more like 2^32 (maximum number of bits in a block).

[stringhandler]

64kb ought to be enough for anybody :D

Let me try with some bigger numbers.

[apoelstra]

BTW you can totally "DoS" gcc or clang by defining massive arrays. I'm not totally convinced this is a problem.

[Sahilgill24]

The difference is gcc/clang don't materialize the array at compile time so we can't DoS them at compile time because they lazily record the size which is an O(1) task and only hard error after the ~2^62 bytes I think.
For simplicity, it builds N nodes and N merkle roots, which is proportional to N (N is the size of the array), to mirror this behaviour the best way would be to set a hard limit.

[apoelstra]

The difference is gcc/clang don't materialize the array at compile time

Yes, they do. The precomputed libsecp256k1 tables cause issues all the time for me because of this and I have to reduce the number of parallel compilations I do.

[Sahilgill24]

Yes, they do. The precomputed libsecp256k1 tables cause issues all the time for me because of this and I have to reduce the number of parallel compilations I do.

oh , Ig my understanding was a bit wrong about it, I shall look into it once again.