[STAL-2698] Handle effectively infallible v8 call failures

[jasonforal]

What problem are you trying to solve?

We currently assume that because we can guarantee valid input to certain v8 functions, that those functions are infallible, and so we unwrap the returned Option (example 1, example 2).

However, this isn't always the case. In particular, there is a race condition where:

1. JavaScript is executing and calls into Rust via a deno_core op
2. The execution thread enters the deno op.
3. The watchdog thread sends terminate_execution to the v8 isolate, causing further calls to that isolate to fail until cancel_terminate_execution is called.
4. The op makes a fallible call to v8.

What is your solution?

Instead of unwrapping the Option for fallible v8 calls, we either ignore the failure or substitute it with an uninitialized value (null, an empty object, etc). This is done via an explicit function: swallow_v8_error (see for in-depth documentation).

Before

I ran the analyzer on a monorepo with over 20k files using a timeout duration of 1 ms. About 3 seconds (~100 rule executions) into analysis, the race condition triggered, causing an panic:

After

I ran the analyzer on the same monorepo with the same timeout duration and logged the number of timeouts.

This PR shows a 100% success rate in timing out v8 without panics: (over 57k timed out rule executions in this case)

Alternatives considered

What the reviewer should know

• There are still some places we unwrap v8 calls -- for example here. This is because calls like this are performed only once upon the runtime initialization, and all future JavaScript rule executions depend on that call not failing.