Fix: handle stack frames in the correct order

[andreabergia]

Commit f3c64ee removed ObjArray and replaced its usage with standard JDK classes. In Interpreter, in particular, an ArrayDeque is now used to store
cx.previousInterpreterInvocations, which is used to generate the stack frame information. However, there is one place where toArray is done, and the behavior for ObjArray and ArrayDeque are different (swapped).
Unfortunately no tests actually ends up exercising this difference due to the interpreter function peeling optimization done in #1510.

We have discovered this problem because, in ServiceNow's fork, we currently need to disable the function peeling optimization.

I cannot figure out how to write an unit test for this problem, though. Any ideas?

---

To verify that the behavior are different, I've written this code:

class ObjArrayTest {
	public static void main(String[] args) {
		var objArray = new ObjArray();
		objArray.push(1);
		objArray.push(2);
		objArray.push(3);
		System.out.println("objArray: " + Arrays.toString(objArray.toArray()));
	
		var deque = new ArrayDeque<Integer>();
		deque.push(1);
		deque.push(2);
		deque.push(3);
		System.out.println("ArrayDeque: " + Arrays.toString(deque.toArray()));
	}
}

It prints:

objArray: [1, 2, 3]
ArrayDeque: [3, 2, 1]

[gbrail]

I could see how this would be a problem! I think this is a fine solution.

As for testing, is there a way to verify the stack traces in interpreted mode? I'm not totally sure where this stuff happens but I figure that we'd get backwards stack traces in this case, would we not?