Fix special 'null' cases when inferring array literals

[dcodeIO]

This PR addresses the issues reported in #1083, except that it doesn't yet disallow inferring null to usize if the contextual type is not a reference type as this would be a breaking change I'm not sure about yet.

Referencing the snippets of the original issue:

let arr1 = [null, "a"]; // should compile but produce error

This now compiles due to inferring logic skipping null literals, and applying the nullable flag afterwards.

let arr2 = [null];      // should produce error but compile

This now produces an error because null has been skipped and the final element type is auto. More of a side-effect that would play well with disallowing null in non-reference contexts, if we decide to go for that.

let arr3 = [1, null];   // should produce error but compile for now

This still compiles. While the null literal is skipped, i32 is not nullable so remains i32 so null behaves like it's in an i32 context. In 32-bit, its usize type is implicitly convertible to i32. Disallowing null, as mentioned above, would result in an error here.

let arr4 = [[1], [2]];  // currently produce compiler error

This now compiles since the inference logic has been moved to the resolver. Infers i32[], i32[], then i32[][].

[dcodeIO]

Instead of making null without context an error, last commit makes it a warning and adapts the fix so that all of the given problematic cases compile, keeping things backwards compatible except that users might notice the new warning. In particular

let arr2 = [null];      // should produce error but compile

remains legal, but emits AS226: Expression resolves to unusual type 'usize'. for soundness. The same warning is emitted by

let arr3 = [1, null];   // should produce error but compile for now

instead of erroring out.

Also updated the respective cases in stdlib and our test cases so that no warning is emitted.

[MaxGraey]

Agree, emit warning is better for those cases