This is a second attempt at addressing the "OutArray problem" from #806.
Closes #727.

The problem

In GDScript, the subtyping relationship is modeled incorrectly for arrays:

var typed: Array[int] = [1, 2, 3]
var untyped: Array = typed   # Implicit "upcast" to Array[Variant].
untyped.append("hello")      # Not detected by GDScript parser (no-op at runtime).

The solution: AnyArray

This PR introduces a new type AnyArray, which can store any array, typed or untyped.
AnyArray thus provides operations that are valid regardless of the type, e.g. len(), clear() or shuffle().
Methods, which can be more concrete on Array<T> by using T (e.g. pick_random() -> Option<T>), exist on both types.

AnyArray does not provide any operations where data flows in to the array, such as push() or insert().

Conversions

Deref coercion allows every &Array<T> to be treated as &AnyArray. This is true even for T=Variant.

To upcast Array<T> values to AnyArray, use Array::into_any(). You can explicitly downcast an AnyArray using try_into_typed() and try_into_untyped().

Compatibility

I've put a lot of emphasis on keeping existing code working as much as possible:

• ✔️ engine_method(&variant_array) keeps working due to Deref coercion.
• ✔️ let a: VariantArray = engine_method() also keeps working. Methods return untyped arrays.
• ✔️ virtual_method(a: VariantArray) signature stays as well.
• ❌ virtual_method() -> VariantArray now returns AnyArray. This is breaking but now allows returning both typed and untyped arrays, using into_any() conversion.
• ✔️ array!, varray! expressions keep working as-is and as expected.

New features:

• You can now pass typed arrays (Array<T> for T != Variant) for engine parameters that previously only accepted VariantArray.
• You can now operate on element-agnostic arrays, without knowing whether they're typed or not. This opens some use cases that weren't previously possible.
• Some internal patterns can be represented more nicely, e.g. the InnerArray methods that return a possibly-typed array, and currently need a combination of generics + unsafe to be used correctly.

Open points

Naming

• AnyArray means "it can represent any array, either typed or untyped". The type erasure is somewhat expressed through "any". Not 100% happy with it though...
• I originally considered OutArray due to data only being allowed to flow out of the array. Kotlin uses out variance. Important, this is not read-only. clear(), shuffle() etc. are perfectly fine, as they don't need to insert an unknown element type.
• Another option would be CovArray for "covariant array", but this gets a bit more towards type theory and may not be obvious at all.

Complexity

It does introduce a new concept that doesn't exist in GDScript, but allows for more robust code when dealing with untyped or maybe-typed arrays. There are no more no-ops or panics when accidentally inserting into arrays.

An alternative would be to just allow Array<T> to deref to VariantArray (maybe needs separate type?) and thus model GDScript's (broken) relations. It would mean we have to introduce panics or no-ops when the VariantArray is in reality pointing to a typed array.