This bug can be recreated by running
`tone(345, 1, 50, 4)`
as well as a big time-wasting spin-loop every `update()`.

This bug can be recreated by running
`tone(345, 2, 50, 4)`
as well as a big time-wasting spin-loop every `update()`.

The old logic could cause sound glitches if a tick comes in earlier than expected.

This means that tone() calls that are made at different times within a frame all start at the same time.

Also fixes up the code that pauses audio, which was buggy and some of which was dead code.

Each tone call is split into sections, each of which has a start volume and
frequency, and an end volume and frequency. Each section is played
continuously until either its end *tick* is reached, ending the section and
starting the next, or its end *time* is reached, which holds the tone there
and stretches it out until its end tick is reached.

Add a short fade-out period to the end of all tones to prevent audio clicks and pops.

The web runtime doesn't run on NodeJS, but was using node types. This was causing issues because some node types override the DOM types, like setTimeout().

Adding `"types": []` to tsconfig.json prevents types in node_modules/@types from being used, including node_modules/@types/node, which is installed because it is a dependency of our dependencies.

This commit reworks the frame timing of the runtime ensuring a regular update
every frame on 60 fps monitors, while still supporting other framerates both
higher and lower. It achieves this by measuring the framerate continuously, and
updating in a requestAnimationFrame() callback when the framerate is close to
60, but switching to a setTimer() timing scheme otherwise.

This keeps animation smooth on a 60 fps screen, but keeps updates both
full-speed and at regular 16ms intervals on a 30 fps screen, important for
making tick-based audio timings accurate. This also has the effect of allowing
you to run the runtime in a minimised or background browser window. This is
really improves the audio experience, allows you to run games or demos in the
background, and also makes it much easier to test netplay without having to
keep many windows on screen at once.

Previously favicon.ico was being requested from wasm4.org when developing
locally. This won't work if the user is offline, the website goes down
etc. It also doesn't work well with the new CORS headers I'll introduce
in the next commit.

Setting these security headers grants us access to higher precision time. This
improves our ability to pace frame timings and make accurate performance
measurements. I hope to take advantage of this to improve the devtools in the future.