napi_get_value_string_utf16 computed bufsize - 1 as the destination capacity
and stored the null terminator at buf[bufsize - 1]. With a non-null buffer and
bufsize == 0, bufsize - 1 underflows to SIZE_MAX, so the entire JS string is
copied into the zero-length buffer and the terminator is written at
buf[SIZE_MAX] -- an attacker-sized out-of-bounds write reachable from any native
caller passing (buf != nullptr, bufsize == 0) (CWE-191 -> CWE-787).

This affected both the Chakra and JavaScriptCore backends:
- Chakra (js_native_api_chakra.cc): gate the copy on bufsize != 0 (mirroring the
  upstream Node implementation). The latin1/utf8 siblings shared a milder bug --
  with bufsize == 0 they took the slow path (a needless allocation) and stored
  the terminator at buf[0], one byte past a zero-length buffer; both now
  short-circuit bufsize == 0 too.
- JavaScriptCore (js_native_api_javascriptcore.cc): the utf16/latin1/utf8 getters
  delegate to JSString::CopyTo*, which underflow bufsize - 1 and always write
  buf[size] = 0. Short-circuit bufsize == 0 at the getter before calling the copy
  helper.

V8 already handles bufsize == 0 correctly and is unchanged.

Add a native regression test (this path is not reachable from JS) that calls
napi_get_value_string_utf16 with a sentinel buffer and bufsize == 0, asserting
nothing is written and the reported length is zero, while a normally-sized
buffer still copies and null-terminates. Runs on Chakra, V8 and JavaScriptCore;
guarded off the V8JSI backend, which does not expose napi_get_value_string_utf16.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>