[oscars-integration] compare test262 results for oscars integration vs main

[shruti2522]

follow up #5480

To get the test262 suite cleanly passing on this branch and reach expected conformance, we first need baseline of the regressions. currently re enabled the test262 CI workflow. This allows us to compare our CI results against main and strategically fix the actual failures introduced by the integration

[jedel1043]

I also tried running the tests locally, but on every run the tests got slower and slower after every completed test. Might be either a memory leak problem or a memory fragmentation problem? Could be good to run an execution test with Miri to see what's happening there

[shruti2522]

I also tried running the tests locally, but on every run the tests got slower and slower after every completed test. Might be either a memory leak problem or a memory fragmentation problem? Could be good to run an execution test with Miri to see what's happening there

there was indeed a memory leak happening, traced the Gc lifecycle and found that the heap was split into two isolated thread-locals in context.rs, with one for alloc() and a totally different one for gc_collector().

Also, boa_gc::force_collect() was marked a no-op, thus the memory was never actually being swept during the entire test run. Fixed it by unifying the thread-locals into a single MutationContext::global() and implemented the sweep phase for force_collect

While digging into this, I also tracked down a big memory leak in oscars. Added non_root_count to count internal references, since it was missing in the mark sweep branded collector