Mouse-dragging idiom does not work

Create a model with a go (forever) button, and give it this code:

to go
  if (mouse-down?) [
    while [mouse-down?] []
    show "No more Mr. Mouse"
  ]
end

Click on the View. In JVM NetLogo, you will see the message "No more Mr. Mouse". In Tortoise, the code for that line will never be reached. The mouse is never given a chance to update whether it's down or not, since the JS for while [mouse-down] [] is a while loop that dominates control of the system.

This could maybe be fixed by actually having while compile to recursive(esque) setTimeout calls. It's kind of gross, but... it would maybe get us better NetLogo semantics. I'm not sure if that would work out well with how we're currently throwing StopInterrupts, though. The whole things a big mess of wonky control flow that doesn't translate well into JavaScript.

This problem also prevents Mouse Drag One Example from working correctly (since it, too, goes into an endless while loop).

Discovered while investigating #150.

Start with the generated JavaScript for while [mouse-down?] [] and the control-flow handling around StopInterrupts. Reproduce the supplied model and compare its behavior with JVM NetLogo, then check the Mouse Drag One Example. Done means mouse state updates during the loop and both cases reach the expected message or drag behavior.