HakunaJsonWriter buffering improvements

[jampukka]

HakunaJsonWriter fills a byte[] buf and flushes it to the servlet output stream. Two costs scale with response size rather than feature count: how often that flush turns into a write(2), and what each write path computes before it can rule one out.

• BUF_LEN: 8k -> 64k
• Sized to be held per concurrent response, not to be optimal for one: 256k measured no faster on the same response, and costs four times the memory under load.
• SLACK / FLUSH_AT (concept)
  • One constant every fixed-width write path checks pos against, in place of each computing its own worst case
    • (pos + 2 + 22 + 1 + 22 + 1 + 2 * f.maxDecimalsOrdinate() >= BUF_LEN and 26 others).
  • SLACK is 128
    • the longest single non-string write is a 4D coordinate, four doubles at their widest plus separators, about 100 bytes.
    • Not a tuning knob: the smallest power of two that covers the worst case.
    • The per-site expressions were not constant-folded
      • maxDecimalsOrdinate() is an instance field read, on a call site taken once per coordinate.
    • String paths keep their own pos + len + … checks; their length has no fixed bound.