feat: add deno_web APIs like setTimeout

[bajtos]

Add JS APIs from deno_web crate.

Most notably:

• Events and AbortController
• TextEncoder and TextDecoder (will be needed for WASM)
• File, FileReader and Blob
• MessageChannel, structuredClone and friends
• atob and atoa (will be needed for WASM)
• setTimeout, setInterval, and friends
• Performance APIs
• Streams (ReadableStream, WritableStream, etc.)
• URL and friends

See #7

[bajtos]

@juliangruber This pull request is adding many new public APIs, significantly increasing the amount of stuff we will need to support in the future.

Most of these APIs are lightweight (e.g. AbortController, events, Performance, URL), so I don't anticipate any need to restrict their usage when we start limiting resource consumption.

Many other APIs will be needed in the future:

• TextEncoder, TextDecoder and btoa (or atob?) are required by wasm-bindgen
• Web Streams are needed for Fetch API. We will need some concept of streams anyways, I think it's best to build on a standard, even if it's not the greatest API.

Could you please review the list of the new APIs and let me know if there is anything you would prefer to remove from the global scope (make it private)?

Do you have any opinions on how to test this? I don't want to replicate the Deno test suite or Web API conformance tests. At the same time, I think it would be nice to have some sort of smoke tests to verify that the APIs are correctly exposed. But that's quite a lot of work, considering how many new APIs are added in this PR.

[juliangruber]

• Web Streams are needed for Fetch API. We will need some concept of streams anyways, I think it's best to build on a standard, even if it's not the greatest API.

+100, always go with the platform / ecosystem.

Could you please review the list of the new APIs and let me know if there is anything you would prefer to remove from the global scope (make it private)?

I'm not sure how to think about this. In general, everything that is expected in a modern JS platform should be here, unless its implementation is problematic for Zinnia's purposes.

Do you have any opinions on how to test this? I don't want to replicate the Deno test suite or Web API conformance tests. At the same time, I think it would be nice to have some sort of smoke tests to verify that the APIs are correctly exposed. But that's quite a lot of work, considering how many new APIs are added in this PR.

What about just checking whether the global is defined? And then progress with regression tests where necessary. We could also add some more tests to one specific module, which "proves" that in general integrating modules from Deno works.

[bajtos]

Cool.

What about just checking whether the global is defined? And then progress with regression tests where necessary. We could also add some more tests to one specific module, which "proves" that in general integrating modules from Deno works.

I will land this PR as-is and open another PR to add some smoke tests. I'll see if I can find a reasonably easy way to add these tests en masse.