RFC: internally represent CompositeValue with both a backing map[string]Value and []Value

[thesephist]

Both the V8 JavaScript engine and the Lua runtime represent composite list/dictionary-like data structures in the respective languages runtime-efficiently by having both a growable array and a hash map that backs a single data structure.

Because Ink also uses its only native data structure, the composite value, as a list with integer indexes, it may be interesting to also try to represent Ink composite values with a backing growable array in addition to a hashmap. In other words, this RFC updates the internal representation of CompositeValue to also include []Value, in addition to map[string]Value.

I think this can be done in a way that's transparent to the language, and without any meaningful performance regressions in composite value-set operations now including a string-to-integer conversion check. But it's not urgent, and it requires some investigating.

[thesephist]

In retrospect, this is obviously a good idea. But I'm going to not implement it in this interpreter and roll this optimization into a future performance-focused interpreter. I'd like to keep the Go implementation as simple as possible.