Makes `ztracing` spans work on the web, by mapping them to browser
`performance` APIs.

Since calling into JS from wasm has fairly high overhead, we instead
have a dedicated reporter task that threads send timing information to.

This approach significantly decreases the performance overhead of the
span-capturing thread (which is usually the performance sensitive one),
at the expense of:
- erasing thread information for spans in the browser devtools
- potentially dropping events if the bounded queue becomes full

The first issue can be mitigated by some slightly more sophisticated
capturing, along with a fixup script, which will come in a later PR

---

Release Notes:

- N/A or Added/Fixed/Improved ...