Unnecessary memory use in some tests causes false failures on constrained hardware

The XS JavaScript engine is designed to run on resource constrained embedded hardware. It runs EcmaScript 2021 on devices with as little as 16 KB of RAM.

We have typically run Test262 against XS running on a computer where there is no practical limit on the memory available to the tests. We have slowly been working on running Test2652 on embedded devices as well. Our current focus is the ESP32 where the default VM size we test with is 64 KB. Our hope is to eventually run Test262 on devices with less memory, so this is a first step.

As expected, some tests fail because of memory exhaustion. That's probably inevitable for some tests. But, there are tests which would pass if they required less memory. A good example is this test Array.prototoype.copyWithin:

https://github.com/tc39/test262/blob/9f2814f00ff7612f74024c15c165853b6765c7ab/test/built-ins/TypedArray/prototype/copyWithin/coerced-values-end-detached-prototype.js#L34-L40

Here the 10,000 element array causes an allocation failure of the TypedArray on ESP32 which prevents the test from completing. Reducing this to 1000 allows the test to pass. The larger array size does not appear to contribute to validating conformance with the standard. It would be beneficial for developers using XS to know that it implements the correct behavior, so we'd like tests like this to pass.

There are several possible ways to resolve this -- changing the test for all execution environments, adding some kind of configuration test, etc. Before diving into that, I wanted to see if test262 is open to addressing issues like these that impact the use of test262 to validate JavaScript on constrained device targets.

Start with test/built-ins/TypedArray/prototype/copyWithin/coerced-values-end-detached-prototype.js, especially lines 34-40, and compare the 10,000-element allocation with the reported 1,000-element case on ESP32. Determine an agreed approach for constrained targets without weakening conformance coverage; done means affected tests can run successfully within the stated XS memory limit.