minifb native runtime has inconsistent framerate on macOS
System: I'm on a 2019 Intel Core i9 MacBook Pro running macOS 12.5.1 Monterey.

Context: I'm experimenting with a tool ([`pico8_rom_tool`](https://github.com/VyrCossont/pico8_rom_tool/tree/f3b45b418a1ebaf2504e926d1c8172c38a91c443)) to translate a subset of PICO-8 music to Rust code for playback in WASM-4.

This test WASM-4 cartridge [(zipped `.wasm`)](https://github.com/aduros/wasm4/files/9483615/atelier_esri.wasm.zip) [(source)](https://github.com/VyrCossont/AtelierEsri/blob/926afd5f42ce51278b1c31b8796d018d50e7e366/src/lib.rs) currently plays the treble part of the first few bars of Ode to Joy, extracted from this PICO-8 cartridge with `pico8_rom_tool`:
![ode_to_joy p8](https://user-images.githubusercontent.com/26195552/188291670-ab82bae2-f91e-4f2f-ae86-6ad4b5a2a197.png)

It does not play properly in the currently shipping macOS minifb native runtime for WASM-4. It sounds like the frame timings are very slow, by multiple frames, and as a result, the music is slow, unpredictably timed, and thus almost unrecognizable. This mostly goes away if the runtime's window is clicked at least once, at which point it seems to run at normal speed.

I've captured audio from each of PICO-8, the minifb native runtime without clicking the window, the minifb native runtime with clicking the window, Firefox using the web runtime, and a [resurrected glfw build of the native runtime](https://github.com/VyrCossont/wasm4/tree/resurrect-glfw-backend), and visualized them in Audacity:

<img width="1904" alt="ode to joy music diagnostics" src="https://user-images.githubusercontent.com/26195552/188292197-307f830f-6164-4dd4-925c-7855099538f5.png">

Here I've zoomed in on the first few notes. (Note that Firefox won't play any audio until the player is clicked, so the first note is missing from that version.)

<img width="1904" alt="ode to joy music diagnostics zoomed to first few notes" src="https://user-images.githubusercontent.com/26195552/188292214-9f6442da-98f5-4cd3-82b6-5f2cf8348c7c.png">

The minifb native runtime (after clicking) sounds nearly as good as PICO-8. The glfw native runtime is close but accumulates some drift after a few notes. The web runtime in Firefox is worse than either native runtime (note the wider spacing between notes) but recognizable. I've also tried it in Safari, which is not included in the visualization, but sounds roughly equivalent to Firefox.

I have not yet tried this experiment on the native runtime on other platforms. I'll look at Windows after filing this bug.

Summary:
1. There's clearly something wrong with the macOS minifb build where it's not running at full speed when the runtime starts. I don't have an idea what's causing this; suggestions are welcome.
2. In general, WASM-4 has no mechanism for timing music or sound effects that is independent of counting `update()` calls. Music and SFX are extremely sensitive to small delays in frame timing. Adding an elapsed-real-time API independent of `update()` would improve the developer and user experience for anything related to audio, and probably also in general.