State the versioning policy for `gc-stats --json`

[tmcgilchrist]

"version": 2` is emitted but nothing says what it means or when it changes, so it cannot be relied on. That is how the two backends came to emit different key sets while both claiming version 2, which #117 fixes.

Proposed policy, which is what the fixes in #117 already assume:

1. The key set is the same for every supported OCaml version. A backend that cannot compute a value emits the key with null. null means "not available on this runtime", 0 means "measured as zero".
2. A key means the same thing everywhere, across backends and across the human-readable and JSON output.
3. Consumers must ignore keys they do not recognise, which is what makes adding a key non-breaking.
4. version bumps only on a breaking change: removing a key, renaming it, changing its type, or changing its definition.

By rule 4, #117 is a breaking change, since total_heap on the 5.0 backend goes from a number to null. Folding it into version 2 rather than bumping seems fine: the version field was added in f505bf6, three days after 0.5.4 was tagged, so no released version emits one at all and nothing on opam has ever seen version 1 or 2.

A short section in the README would be the best place for this, and gives somewhere to record what the keys mean and their units, which is not written down anywhere today.

[edwintorok]

We could have a "dummy" value that we print as JSON and promote back into the source tree.
We can also keep a v1, v2, etc. json as a copy in the source tree that we can compare against, to reject incompatible changes without bumping version numbers.
(we can still make incompatible changes as long as we bump versions of course).

(The dummy value is not strictly required, we could also walk a Jsont.Repr.t and emit that, but is simpler).

Ideally we could generate and store a Json schema, but I don't see existing integration between jsont and jsonschema on opam (there are integrations with yojson though, although yojson can also produce non-standard JSON if we're not careful), so for now storing versioned JSON examples is probably the simplest solution, and we can also use that as part of the documentation.