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.

Oh, right, it is already cached. What do you think about getting this info at startup to avoid the need for a callback? So we wouldn't need to throw VM.Pause every time (it's pretty expensive, and looks like MIDlets call getProperty a lot of times)