Add arrays: literal, indexing, index assignment, and len()

[erichanwang]

The AST already had ARRAY/INDEX/INDEXSET node types and a parser that built them, but neither the interpreter nor the codegen actually did anything with those nodes yet. This fills that gap end to end and, more importantly, pins down the one thing the parser left undecided: what happens on a bad index.

Why this was needed: arrays are the biggest remaining feature and the one that forces a heap object type through every stage - lexer, parser, both Value representations, both codegens, and runtime.c.

Semantics chosen (documented in syntax.txt), picked so the interpreter and the compiled backend can agree exactly:

• An index must be a Number; it truncates toward zero via a C (long) cast, the same operation on both sides.
• Reading with an out-of-bounds index, a negative-after-truncation index, a non-numeric index, or indexing something that isn't an array, produces an ERROR value, the same style as the existing division-by-zero and undefined-name errors, instead of crashing or reading garbage.
• Writing (arr[i] = v) under any of those same invalid conditions is a silent no-op, but the index and value expressions are still evaluated - so a function call used as either one still runs and can still print. Getting this half-evaluated case wrong is exactly the kind of drift edge_cases.lang was written to catch elsewhere in the language.
• Arrays are reference types: copying a Value (assignment, a call argument, an array element) aliases the same backing storage rather than deep-copying. The interpreter gets this via shared_ptr<vector<Value>>, matching what the compiled side gets for free from passing a Value* pointer around.
• len(arr) is a reserved builtin intercepted ahead of the normal function-call path in both backends - it is not a real function, so a program cannot declare its own len.
• Indexing stays single-level: grid[0][1] does not parse as chained indexing (pre-existing parser limitation). syntax.txt documents assigning the inner array to a temporary as the workaround.

What I measured:

• ./run_tests.sh: all 15 .lang files pass (13 pre-existing plus two new array files), interpreter and compiled x86-64 output diffed identically on every one.
• g++ -O2 -std=c++17 -Wall -Wextra -o /tmp/axc compiler.cpp: clean, no warnings.
• ./benchmark.sh on bench/workload.lang (which has no arrays, so it isolates whether this change touched the hot path): 2.9x-3.9x compiled vs interpreted across repeated runs, same noise band the project was already at before this change - arrays did not regress the benchmark.

New test files, written in the same spirit as edge_cases.lang - hunting for backend drift rather than just proving the happy path:

• arrays.lang: literal construction, indexing, len(), index assignment, aliasing across variable and function-argument boundaries, nested arrays via the documented temporary workaround, indexing by a computed (non-literal) expression, and the empty array.
• array_edge_cases.lang: out-of-bounds reads both directions, negative indices, non-integer index truncation, indexing a non-array, indexing/len() on a value that is itself an error (must propagate rather than being masked by an "index out of bounds" message), and out-of-bounds/invalid writes where the index or value expression is a function call that prints - to confirm the no-op still lets the side effect through.

What a reviewer should check:

• That the index/write semantics above are actually what's wanted - it's a from-scratch design decision, not dictated by any existing convention in the codebase.
• runtime.c's rt_array_get/rt_array_set and compiler.cpp's arrayIndex/execStmt's INDEXSET case check conditions in the same order (error propagation, then type checks, then bounds) - that ordering is what makes the two backends agree, not just coincidence.
• I did not add the for-loop stretch goal in this pass; arrays alone touched every stage and I wanted the full edge-case pass on them rather than splitting attention.