Analyse UI performance, fix low-hanging-fruit items

[jamesyoungman]

I think some of the design choices in the UI implementation have bad performance characteristics. For example, we update the I/O and Alarm status panels after every instruction. This could be the reason why it takes the simulator several seconds to read the 360 lines of the "hello.tape" example program even though (1) the data is in memory, and (2) the simulated tape reader should be able to do this in under a second.

I'd like this code to be usable on portable devices (e.g. tablets) and it needs to not eat battery.

[jamesyoungman]

The obvious performance bottlenecks are

1. I/O status updates (~2ms per tick)
2. Rust tracing code (~0.2ms per tick)
3. JavaScript marshalling (for values returned from WASM to JS) (also ~0.2ms per tick).

The UI update performance issue can be mitigated by reducing UI update frequency to, say, once every 100ms. The overhead of the tracing and WASM/JS marshaling infrastructure is much less tractable. But it is important, as we would want the time taken for the simulator to emulate an instruction to be comfortably less than the time taken by the original machine, so that we can reliably run at the same speed as the original machine.