Some tests assert V8's exact error message wording, so non-V8 runtimes fail on prose

To see how far a non-V8 runtime gets, I ran the suite under Bun 1.3.14 (JavaScriptCore)
on Linux, with the addons rebuilt with GCC and the tests spawned the same way the node
implementor does. 43 of the 48 test files pass. Of the five failures, two are genuine
Node-API gaps in Bun (zero length external strings and Float16Array in the typed array
APIs, both since fixed on Bun's main branch). The other three fail only because the test
compares the thrown error's message text against V8's exact wording, and JavaScriptCore
words the same conditions differently. The same three files fail identically on Windows
with MSVC-built addons, which is where the quoted output below comes from.

The affected assertions:

Three files, seven assertion sites, and it comes down to two JSC strings. Each run stops
at its first failing assertion, so the later sites in each file were confirmed by
evaluating the same operations directly under Bun in strict mode; JSC uses the single
Attempted to assign to readonly property. message for both the read only data property
and the getter-only accessor cases.

A representative failure from the run:

AssertionError: The input did not match the regular expression /^TypeError: Cannot assign to read only property 'readonlyValue' of object '#<MyObject>'$/. Input:

'TypeError: Attempted to assign to readonly property.'

and for the BigInt case:

Comparison {
+   message: 'Out of memory',
-   message: 'Maximum BigInt size exceeded',
    name: 'RangeError'
  }

What these assertions actually verify is real Node-API behavior: that
napi_define_properties produced a property that rejects writes with a TypeError, and
that the engine's own RangeError from an oversized BigInt propagates out of
napi_create_bigint_words as the pending exception. That part holds in Bun. The message
text on top of it is engine identity rather than conformance, and every non-V8 engine
(JSC here, Hermes and SpiderMonkey elsewhere) words it its own way, so as written a
conformant runtime scores red on strings it cannot change. The regexes came along
naturally with the ports from nodejs/node, where a single-engine assumption was fine.

A few possible directions, and I would rather follow your preference than pick one:

1. Assert the error type and the behavior (the write throws and does not take effect,
   the BigInt call throws a RangeError) and drop the message text entirely.
2. Keep a message assertion but loosen it to a shape every engine can meet, for example
   just /TypeError/, or name plus a much weaker pattern.
3. Keep exact messages but make the expected strings per implementor, in the same spirit
   as features.js already being per implementor.

Happy to send a PR for whichever direction you want, or none if you would rather handle
it differently.

先从 test_constructor/test.js、test_properties/test.js 和 test_bigint/test.js 中的断言位置开始，然后在 Bun 或其他非 V8 runtime 下运行这些测试。确认 maintainer 对处理引擎特定消息所偏好的方向；完成的标准是，测试在不要求 V8 的确切措辞的情况下验证所述行为，并在相关 runtime 中通过。