[Rust] Change representation of Value for performance improvement

[bugarela]

• I have read and I understand the Note on AI-assisted contributions
• Changes manually tested locally and confirmed to work as described
  (including screenshots is helpful)
• Tests added for any new code
• Documentation added for any new functionality
• Entries added to the respective CHANGELOG.md for any new functionality

[github-actions]

Benchmark Results

Benchmark	Time
evaluator/tictactoe	672.14 µs
evaluator/JMT	43.71 ms
tictactoe/rust	1.50 s
tictactoe/typescript	4.09 s
tuples/rust	1.62 s
tuples/typescript	9.23 s

[romac]

What a performance boost! 🚀

[erickpintor]

I dug a bit on why this change made such a difference, resulting on this compile time assertion here.

The bottom line is: the imbl crate have optimizations that are well suited for small values, often holding them in the stack before creating their internal heap-allocated trees. Previously, Value had a size of 72 bytes in the stack, which forces imbl to start allocating on the heap soon and often. Now the size of Value is 8 bytes, which makes more use of imbl inline stack allocation.

As an experiment, I've replaced the use of ImmutableVec in Value::Tuple with a simple Rust Vec instead and that change alone gives a boost of ~60%:

main:
tuples/rust             time:   [3.8570 s 3.8728 s 3.8897 s]

main (tuples are vectors):
tuples/rust             time:   [1.5432 s 1.5706 s 1.5993 s]
                        change: [-60.113% -59.445% -58.736%] (p = 0.00 < 0.05)
                        Performance has improved.

This serves as further confirmation that imbl was indeed struggling to host values before.

It's worth noting that this patch also promotes some degree of memory fragmentation as simple values like integers (that are cheap to copy) are no longer stack allocated and will get scattered around the heap a lot. However, quint specs aren't as long lived as real programs so, my intuition is that this fragmentation won't impact us that much.

This is all worth considering as we work on this data structures in future iterations of the rust backend, though.