Add a streaming JSON parser

[SeanTAllen]

The json package could only parse a whole document held in memory. This makes JsonTokenParser an incremental streaming parser: feed it bytes as they arrive with feed(), it emits tokens as they complete through the notifier, and it builds no tree, so the caller controls how much memory the parse uses. A raw-notifier consumer that drops the tokens it doesn't need stays flat however large the document.

Two API changes come with it, both breaking for JsonTokenParser users (JsonParser is unchanged):

• Tokens now carry their own value — JsonTokenKey/JsonTokenString/JsonTokenNumber are val classes with a .value field, replacing last_string/last_number on the parser.
• The parser is driven with feed() / finish() instead of parse().

A key or string value that fits within a single fed chunk with no escapes is a zero-copy view into that chunk rather than a fresh copy. JsonReassembler folds a token stream back into a JsonValue when the caller wants the tree, and JsonParseLimits bounds depth and string and number length for untrusted input.

Design: #5655

Performance

These are rough numbers from a simple single-actor benchmark on one machine (16-core WSL2), not a rigorous benchmark suite — read them as direction, not precise figures. Best of 40 timed runs after warmup, one scheduler thread (--ponymaxthreads=1), peak memory from getrusage. The technique carries built-in inaccuracy: best-of-N reports the least-interrupted run, so it flatters; garbage-collection pauses add variance, worst on the tree-building (batch) path; and peak memory is the process high-water from ru_maxrss, which is coarse. Treat them as indicative, not authoritative.

Zero-copy string views versus the same parser decoding a copy of each string.

Throughput (MB/s parsed)

document		views	copy	views faster by
100-char strings	token	~185	~111	1.7×
	batch	~85–115	~48–74	~1.5× (GC-noisy)
10 KB strings	token	~925	~208	4.4×
	batch	~865	~209	4.1×

Peak memory (RSS)

document	views	copy	views less by
8 MB single string	10 MB	26 MB	62%
40k small objects (200-char strings)	58 MB	79 MB	27%

Views win on both speed and memory, and the win grows with string size — copying a big string per value is what the view avoids. For short strings it's ~1.7× faster and 27% less memory; for large strings ~4× faster and 62% less. (For contrast, a byte-at-a-time buffered.Reader ran ~34 MB/s on the 10 KB case — about 27× slower than the shipped code — which the _ChunkReader design avoids.)