fix: assert module in the renderer process

[codebytere]

Description of Change

Closes #39079.

When creating a Node.js Environment, embedders have the option to disable Node.js' default overriding of Error.prepareStackTrace. However, the assert module depends on a WeakMap that is populated with the error stacktraces in the overridden function.

This adds handling to fall back to the default implementation if Error.prepareStackTrace if the override has been disabled.

This will be upstreamed.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixes an issue where the Node.js assert module did not work in the renderer process.

[ckerr]

This looks good but I want to ask about this line:

However, the assert module depends on a WeakMap that is initialized in the overridden function.

I'm wondering if it's possible to ensure the WeakMap somehow is always initialized whether or not the function is overridden; and if so, whether that would be simpler than the approach in this PR?

I haven't read the assert module -- if the above idea isn't practical or is more complex then this fix LGTM.

[codebytere]

@ckerr sorry, i should have phrased that better. It is initialized - it's never populated which means that call will never have its stacktrace. Updated the patch description!

[codebytere]

Upstream PR: nodejs/node#49212

[release-clerk]

Release Notes Persisted

Fixes an issue where the Node.js assert module did not work in the renderer process.

[trop]

I have automatically backported this PR to "24-x-y", please check out #39621

[trop]

I have automatically backported this PR to "25-x-y", please check out #39622

[trop]

I have automatically backported this PR to "27-x-y", please check out #39623

[trop]

I have automatically backported this PR to "26-x-y", please check out #39624