docs: add JSON output format specification

[ReturnKartikey]

This PR documents the JSON output format produced by --benchmark_format=json, as requested in #720.

The existing user_guide.md has an abbreviated example but lacked a complete field-by-field reference. This adds docs/json_format.md detailing:

• All context fields (host, CPU, caches, load averages, schema version)
• All benchmarks fields (iterations, time metrics, aggregates, Big-O, counters, labels)
• Special floating-point handling (NaN / Infinity)
• List mode (--benchmark_list_tests) format
• A complete output example

Also adds a cross-reference link in docs/user_guide.md and updates docs/index.md.

Closes #720

[dmah42]

i think i've changed my mind about #720. keeping documentation in sync with the code is going to be a real pain. it's not that hard for folks to just read the code, or run the tests, to see the json output.

[LebedevRI]

i think i've changed my mind about #720. keeping documentation in sync with the code is going to be a real pain. it's not that hard for folks to just read the code, or run the tests, to see the json output.

Honestly, i was wrestling myself from posting the same yesterday...
I do think there needs to be a spec, but not a user-readable one.

[ReturnKartikey]

Thanks @dmah42 and @LebedevRI for the feedback.... that makes total sense. Manual documentation markdown files inevitably suffer from drift as new metrics and fields are added to json_reporter.cc.

If you're open to it, I'd be happy to pivot this PR from a markdown document to a formal machine-readable JSON Schema (e.g. docs/benchmark_schema.json or tools/benchmark_schema.json) coupled with an automated test in CI:

1. Automated validation in CI: A test (e.g. validating test JSON outputs or reporter test artifacts against the schema) would ensure the schema and json_reporter.cc never go out of sync. Any change to the output format without updating the schema would fail CI.
2. Formalizing json_schema_version: Benchmark already emits "json_schema_version": 1 in context, so having an official schema formally specifies what version 1 covers.
3. Tooling & consumers:** External tools, CI dashboards, and parsers can use the schema directly for automated validation and code generation.

All the field types and descriptions already compiled here can be embedded directly into the schema's description properties.

Would you be receptive to that direction? If so, I'll update the PR with the schema and test.