Fast materialisation attempt

[Szymon20000]

Summary

This adds a JSI JSON tree API that lets native code materialize decoded JSON-compatible C++ data into Hermes values without converting it back to JSON text and parsing it on the JS thread.

The main purpose is to make deserialization/materialization into Hermes as fast as possible. In React Native, Hermes is single-threaded from the JS runtime perspective, so object creation ultimately happens on the JS thread. But many data sources can prepare structured data on other threads first: network calls, database reads, persistence layers such as MMKV, native modules, and cross-runtime data transfer.

This PR adds:

• jsi::JSONValue, a JSON-compatible C++ tree representation
• jsi::IJSONValueFactory, an optional JSI runtime interface for materializing/extracting JSON trees
• Hermes support for creating JS values directly from a JSONValue tree
• a consuming materialization path that can transfer string storage into Hermes when possible
• an experimental runtime-free encoder that can create Hermes SerializedValue payloads from a JSONValue
• a native benchmark under tools/hvm-bench

This is intentionally focused on destination-side deserialization/materialization time rather than total round-trip time. Total time includes producer-side work such as serializing an existing JS object or extracting a JSON tree from JS. In the intended use case, that producer-side work can happen natively and off the JS thread, so the most important metric is how quickly Hermes can materialize the final JS object graph.

Test Plan

Built the release benchmark target:

cmake --build build_release --target serialization-json-bench

[tmikov]

Thanks for putting this together, and for the clear framing around
off-thread materialization - it's a real problem and the benchmark
numbers are encouraging.

That said, I want to be upfront: settling on the right API here is a
substantial design exercise, and not one we're ready to commit to.
There's a real open question about whether the right shape is a tree
like JSONValue, a streaming builder, or something that targets
SerializedValue more directly - each has different tradeoffs for
producer-side allocation cost, string ownership, and key interning, and
any of them becomes a long-term maintenance commitment once it's part
of the public JSI surface. We don't want to land something we'd later
have to live with or break.

So I don't want to leave you with a vague "maybe someday" - realistically
we're not in a position to take this in its current form, and I can't
promise when we'd pick up the broader design.

Really do appreciate the effort, and sorry for the unsatisfying answer.

[Szymon20000]

Thank you @tmikov for taking a look!
Is there anything I can do to make it easier to manage?
I thought about proposing a few different APIs so we can check which one is the easiest to maintain and use.