feat(napi): keep stack traces in a deferred context

[MarkusJx]

Currently, stack traces from the calling javascript context are not preserved, when an error is thrown inside a deferred context (e.g. an async fn). Thus, errors thrown inside async functions always look like this:

[Error: Test] { code: 'GenericFailure' }

Which is not very useful when debugging an application.

Current solution

The npm package trace can be used to add the stack traces to the errors thrown in another thread.

Proposal

This comment shows how stack traces can be added to errors thrown inside a deferred context: nodejs/node-addon-api#595 (comment)

Basically, for the stack trace to be preserved, an error needs to be created in the main thread, so the v8 can keep a reference to the calling function. As the error doesn't contain the error message of an error thrown inside the deferred context, the message and status code must be replaced in the error before returning the error back to the javascript process.

This PR adds this functionality as an optional feature, as creating a new error every time a promise is returned to the javascript process seems wasteful. I did some simple performance tests and the performance impact didn't seem to bad (the compute times seemed to be pretty much unchanged, but I think keeping this as an optional feature would be better).

With this feature enabled, stack traces from errors returned by a promise look like this:

Error: Test
    at test (test.js:28:20)
    at Object.<anonymous> (test.js:58:1)
    at Module._compile (node:internal/modules/cjs/loader:1226:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1280:10)
    at Module.load (node:internal/modules/cjs/loader:1089:32)
    at Module._load (node:internal/modules/cjs/loader:930:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'GenericFailure'
}

This feature was originally requested here: MarkusJx/node-java-bridge#77

[Brooooooklyn]

@MarkusJx could you add a test for it 🤔

[MarkusJx]

Sure, but where should I put the tests?

[MarkusJx]

I've added a test for the stack traces from deferred contexts inside examples/napi/__tests__/values.spec.ts.
I've also adapted the code to return errors, which were created inside the JavaScript process, as those errors already contain a stack trace, instead of the replacement error.

Also, I've noticed that cloning an error which contains raw values (errors from the javascript process) causes the process to crash, as the clone will be freed and the original will also be freed, causing the raw values to be freed twice. I think. Don't know if this is a known issue, but I thought I should mention it.