perf: speed up direct long rendering

[He-Pin]

Motivation

Direct long rendering in sjsonnet was already fairly optimized: it used scratch buffers and digit-pair lookup tables instead of repeatedly allocating Strings on the hot renderer paths. The remaining cost was the /100 loop for every two digits, plus TOML exact-long doubles still went through an intermediate string path and used a math.round guard that saturates near Long.MaxValue.

This uses the jeaiii integer-formatting idea and jsoniter-scala v2.38.17 as references, but applies them conservatively for sjsonnet: the blog-style 1441151881 /100 reciprocal is only safe in a bounded range, so the full Long path uses jsoniter-style Math.multiplyHigh chunking by 1e8/1e16, then digit-pair extraction for int-sized chunks.

References:

• https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/
• https://github.com/plokhotnyuk/jsoniter-scala/releases/tag/v2.38.17 which leverages this

Modification

• Add a shared FastLongRenderer for ASCII Long rendering.
• Route both BaseByteRenderer and BaseCharRenderer through that shared helper.
• Keep TOML exact-Long doubles on StringBuilder.append(Long) and fall back to RenderUtils.renderDouble for non-exact Long values, avoiding the previous math.round(...).toLong saturation case.
• Add renderer boundary/random regression coverage and a committed JMH benchmark so the long-rendering comparison can be reproduced from the PR.

Result

The PR is squashed to one commit on top of databricks/master. The shared code lives under sjsonnet/src, so the optimization is used by JVM, Scala.js, Scala Native, and WASM builds. Local checks covered formatting, JVM tests, compile coverage across JVM/JS/WASM/Native, and renderer tests on JS/WASM/Native.

JMH command:

./mill bench.runJmh ".*LongRenderingBenchmark.*" -f 1 -wi 5 -i 8 -r 1s -w 1s

Local JMH on JDK 21, Apple Silicon, lower is better:

Benchmark	upstream/master	this PR	Change
baseByteRendererLongs	40.280 ± 1.054 us/op	32.865 ± 0.277 us/op	1.23x faster
baseCharRendererLongs	48.081 ± 1.233 us/op	45.992 ± 0.229 us/op	1.05x faster
tomlRendererExactLongDoubles	81.820 ± 0.939 us/op	43.046 ± 1.273 us/op	1.90x faster

The smaller char-renderer win is expected: the existing char path was already optimized with a scratch buffer and digit-pair tables, so most of the new gain comes from removing repeated division and sharing the full-Long chunking logic.