set status to STARTED after invoking isolate's main class

This sets status = STARTED after nativeStart invokes the isolate's main class.

That means the status will be STARTED when the test calls waitForExit, so I had to fix a bug in waitForExit, which was relying on waitStatus to wait until the status is >= STOPPED (i.e. the behavior implemented by the native implementation, which is different from the behavior described in the Java class).

Also, calling updateStatus to update the status to STARTED may call a callback that re-calls Runtime.prototype.waitStatus, which then throws VM.Pause, which we don't want to happen in nativeStart. So I trap and discard the exception.

(Although it seems to me like it would be better to throw VM.Pause only in the initial call to the waitStatus native, which is what my earlier implementation did, rather than every time the callback is called.)

Isolate.start() does:

```
        while (getStatus() <= NEW) {
            try {
                // Note: do NOT use wait(). See comments inside waitForExit().
                waitStatus(NEW);
```

I.e. if the status is <= NEW, then wait until it's > NEW (STARTED, STOPPING, or STOPPED).

But Isolate.waitForExit() does:

```
        while (getStatus() <= STOPPING) {
            try {
                // …
                waitStatus(STOPPED);

I.e. if the status is <= STOPPING, then wait until it's > STOPPED. Which doesn't exist, so if we reach this point, we'll wait forever. Which is a bug in this code that reflects that discrepancy we noticed earlier between the Java description of the behavior of waitStatus and the actual native implementation.

The bug didn't cause a problem before, because without this change, status starts at NEW and then changes directly to STOPPED without changing to STARTED first. So Isolate.start() calls waitStatus(NEW), which doesn't return until the status is STOPPED. And that means the test doesn't reach Isolate.waitForExit() until the status is already STOPPED, so the errant waitStatus call is never reached.

But with this change, status starts at NEW, changes to STARTED, and then changes to STOPPED. So Isolate.start() calls waitStatus(NEW), which returns when status is STARTED. And then the test calls Isolate.waitForExit(), while status is still STARTED, so the errant waitStatus call is reached, and it waits forever.

Thus we need this change to ensure that calling Isolate.waitForExit() doesn't hang when we correctly transition to the STARTED state.