perf: reuse a thread-local scratch buffer for new_from_utf8 transcode

[bartlomieju]

Summary

#2026's simdutf transcode path in new_from_utf8 allocated a fresh Vec on
every non-ASCII string creation. This reuses a thread-local scratch buffer
instead — taken out of the thread-local and put back around the V8 call, so its
borrow isn't held across a potential GC. The buffer is still copied into V8 by
NewFromOneByte/NewFromTwoByte, so only the per-call allocation is removed.

Impact

Incremental over #2026, new_from_utf8 (median of 6):

kind	16	64	256	4096
latin1	−13%	−13%	−15%	−3%
twobyte	−24%	−24%	−18%	−3%

The allocation was the dominant fixed cost at small-medium sizes; it fades
against the copy/transcode for large strings.

Note on the alternative

This is the low-risk half of proposal "3B". A NewRawOneByteString /
NewRawTwoByteString binding could additionally eliminate the copy by
transcoding straight into V8's heap string, but that only helps large strings
by a few percent and requires unsafe V8-internal Factory access + writing
under a DisallowGarbageCollection scope, so it's left as a possible follow-up.

Correctness

All 16 test_api string tests pass (with and without simdutf).

[bartlomieju]

This needs to be rewritten to have a limit on size - otherwise allocating an 100Mb string will permamently leave 100Mb laying around

[bartlomieju]

Addressed in 19eac93. The scratch buffer's retained capacity is now capped: on put-back, put_encode_scratch drops any capacity above ENCODE_SCRATCH_MAX_CAP (64Ki elements — 64 KiB for Latin-1, 128 KiB for UTF-16) with clear() + shrink_to(), so a one-off 100 MB string no longer leaves 100 MB parked in the thread-local. A larger string still transcodes fine; it just reallocates that one time rather than retaining the buffer.

The cap sits comfortably past the sizes where reuse actually helps — per the PR's own numbers the allocation saving has faded to ~−3% by 4 KiB and is dominated by the copy/transcode well before 64 KiB.

Extended new_from_utf8_simd_transcode with >cap Latin-1 (é×100k) and UTF-16 (世×100k) strings followed by a small string, to cover the shrink-then-reuse path. Passes with and without simdutf.