define schema for rpm-ostree status --json

[cgwalters]

Like various parts of the code, this one grew organically and at this point is quite large. We have multiple projects that want to parse it; so this issue is strongly related to #2389

However, I think we need to support "ad hoc" clients parsing it with jq or Python or whatever too. So a documented schema would be good.

[cgwalters]

A question was asked around https://github.com/coreos/rpm-ostree/blob/main/rust/rpmostree-client/tests/fixtures/workstation-status.json - is this both representative (contains all keys of interest) and stable (won't change in the future)?

Representative: That status contains many interesting keys, but not all of them for sure. For example, it doesn't have the initramfs generation.

Stable: This is a trickier question to answer and would be best driven by a discussion around use cases. For example base-commit-meta is reflecting metadata injected by higher level software (in that example, https://quay.io/organization/coreos-assembler/ ). So anything not generated by cosa won't have coreos-assembler.basearch for example. I think we have an endianness bug in rpmostree.rpmmd-repos that may be fixed later. But for most of the other keys: Yes, we're very unlikely to change them.

[cgwalters]

I was thinking about this again, and it also relates slightly to #2326 in that we could add something like rpm-ostree status --treefile -b which would show you the YAML treefile representation that we parsed from the status JSON. That would force us to write bridge code in that direction, and perhaps eventually we try to soft-deprecate the JSON status in favor of again canonicalizing on the treefile format.

(A good middle ground here might be that we eventually stop adding new things to --json)