According to AddressSanitizer, when `sandbox_malloc` causes the
WebAssembly memory to grow in size, every single coroutine on the
sandbox stack gets corrupted. So if `sandbox_malloc` is going to cause
the memory to grow in size, we need to yield so that there are no
coroutines on the sandbox stack while the reallocation occurs.
Somehow, using `rb_class_new_instance` causes use-after-free errors in
the subsequent call to `set_private_data`.
Well, `rb_obj_alloc` is what's used in the normal MRI bindings. I just
replaced the `rb_obj_alloc` calls with `rb_class_new_instance`
at some point in binding-sandbox. Guess that wasn't a good idea.
I've made it so that `Graphics.update` pauses the Ruby VM and returns to
the libretro frontend. Once the libretro frontend calls `retro_run()`
again, the Ruby VM resumes. This allows the libretro frontend to control
the rendering loop.
