fix: optional-chain index opt?.xs[i] over array/ptr-array field (issue 0181)

opt?.xs[i] typed and lowered the index over the optional CONTAINER
(?[N]T); getElementType returned .unresolved, so index_get reached LLVM
with an unresolved element type and panicked. Mirroring the 0101
!-unwrap fix: add lowerOptionalChainIndex (optional_has_value -> some:
unwrap + index (index_gep+load for ?*[N]T, else index_get) +
optional_wrap; none: const_null; merge -> ?ElemType, element-optional
flattened). The typer + dispatch guard compute the element via
ptrToArrayElem(child) orelse getElementType(child), so value-arrays,
slices, many-pointers, AND pointer-to-array (?*[N]T) children resolve.
Null receivers short-circuit (no null deref).

Regression: examples/optionals/0915-optional-chain-array-field-index.sx.
Verified by 3 adversarial reviews, suite 794/0. Filed broader pre-existing
gap 0183 (indexing a non-indexable type panics instead of diagnosing).

examples/optionals/expected/0915-optional-chain-array-field-index.exit

@@ -0,0 +1 @@
+0

examples/optionals/expected/0915-optional-chain-array-field-index.stderr

@@ -0,0 +1 @@
+

examples/optionals/expected/0915-optional-chain-array-field-index.stdout

@@ -0,0 +1,14 @@
+present[0]: 1
+present[2]: 3
+null:       99
+bound:      2
+unwrap:     3
+struct.x:   20
+struct.y:   21
+slice[1]:   6
+ptr[0]:     10
+ptr[1]:     20
+ptr[2]:     30
+ptr null:   99
+u8[0]:      7
+u8[3]:      200