feature: support for `display` command

Jason, Frank, and I have discussed strategies for doing this. The problem is that display must relinquish control of the Javascript thread to give the view a chance to repaint (remember, basic Javascript is single threaded; a website locks while js is running). It must then be able to resume execution as normal. For example:

repeat 50 [ ask turtles [ fd 1 display rt 30 ] ]

Jason suggested having the engine and model code run in a web worker. Then, display just sends out a message to the main thread containing the updates. The downside is that we wouldn't be able to directly call into the engine anymore, which is annoying for debugging and less convenient to embedders. There actually may be a performance hit in that web workers copy messages when sending them. Also, to get the web worker code actually running, we may have to do something weird like concatenating the engine, compat, and the compiled code.

No files, tests, or concrete entry points are named. Start by tracing the display command through the engine and model execution, then evaluate the web-worker approach and its messaging and embedding tradeoffs. Done means display yields for repainting and resumes execution correctly in the example loop.