enable script evaluation using mozbrowser

@marco-c: here's a work-in-progress to enable script evaluation (and thus JIT compilation) by loading the bulk of j2me.js in an *&lt;iframe mozbrowser>*, where it's capable of script evaluation, can still load resources from the app package, and can access privileged APIs through the parent page, with which it communicates over a "dumb pipe."

The top-level page remains *index.html/js*, and you load it as before, but most of its code has been moved to *main.html/js*, and *index.html* contains only the code that accesses privileged APIs, plus its half of the pipe implementation. (The other half, which the child loads, is in libs/pipe.js.)

The "dumb pipe" is really crazy: the child frame sends a message to the parent frame by calling *window.alert*, which triggers a nonblocking *mozbrowsershowmodalprompt* event in the parent (with the message embedded in the event); while the parent frame communicates back to the child frame by changing the child URL's fragment identifier, which triggers a *hashchange* event in the child, upon which the child calls *window.prompt*, which triggers a blocking *mozbrowsershowmodalprompt* event in the parent to which the parent can attach a value that becomes the return value of the *window.prompt* call in the child.

Because *TCPSocket* is one of the APIs that needs to use the pipe, and because the pipe has to *JSON.stringify* the messages that traverse it, there could be a network perf implication to this approach. And the browser machinery of *mozbrowser* itself may impose some penalty; unclear.

There's more work to do here, including a bunch of cleanup but also ensuring we free the pipes after we're finished using them and don't clutter up the iframe history with all the fragment identifer changes. Plus whatever else we need to implement from the *mozbrowser* API to ensure that the page behaves as expected.

But at this point we should first test this with the JIT branch and with various midlets to ensure that it works as expected, enables us to improve overall perf, and doesn't have undesirable consequences.

Originally, I just added this for debugging, but I left it in because I found it quite handy to see the sequence of test files being run. I can remove it or move it to a separate PR if you're unsure about it.

(At times I made test runs even more verbose, logging each individual assertion; which is why I added braces around the `if (ok)` block below. But I removed that logging once I no longer needed it, since it's so verbose it sometimes hangs the browser and causes test failures! And that is presumably even more true now that we've jumped from 5K to 70K assertions.)