GPU: WebGPU back-end

[slomp]

Prototype status:

• 99.99% reliance on WebGPU C API (webgpu.h)
• works with both Google Dawn and Rust's wgpu-native implementations
• multi-threaded command encoding support (but not thoroughly tested)
• CPU-GPU clock calibration happens ad-hoc during initialization (no WebGPU API support)
• Timestamp resolve/copy commands are "batched" (32 queries, due to WebGPU alignment requirements)
• Host access to timestamp buffer is "demultiplexed" across 3 readback buffers operating in round-robin (due to WebGPU async buffer mapping restrictions)
• [TODO] Timestamp queries may not be fully collected during context shutdown (to be addressed by future PRs)
• [TODO] Only one context object allowed until SetupDevice is made re-entrant (to be addressed by future PRs)

The most convoluted portions of the back-end are the "readback buffer reel" and the "clock calibration".

• For readbacks, due to byte-alignment and due to buffer mapping restrictions, I had to resort to a "triple-buffering" scheme to manage timestamp queries. At any given time, one readback buffer is available for instrumentation (QueryID+Resolve+Copy), another is being mapped to the host (wgpuBufferMapAsync), and the other buffer is being processed by Collect(). They rotate in round-robin as needed (Collect orchestrates the rotation by updating an atomic variable).
• For clock calibration, I used an incremental regression scheme to estimate the anchoring cpu-gpu timestamp pair, and the GPU tick period (ns / gpu-tick). The regression is not updated when there's too much uncertainty in the cpu-tick range.

[starmole]

just two small comments around event loop

[starmole]

i would recommend not calling process events here.
a client integrating it will call process events in it's own frame loop.
and it will be very confusing if their callbacks start to come from within Collect.

[starmole]

i would recommend AllowProcessEvents only. AllowSpontaneous is quite dangerous. It can fire on arbitrary different threads.