Categorize `path-info` and C++ path info fields

[roberth]

Is your feature request related to a problem? Please describe.

It's not clear how each path info attribute behaves.
By categorizing them, we introduce clear language to discuss their behavior and think about these fields.
Furthermore, the added clarity will help prevent bugs like #10485

Describe the solution you'd like

• At minimum, document the path info fields
• Apply the categorization using C++ structs
• Change the path-info format, so that users also benefit from the added structure.

Discussion of details below.

Describe alternatives you've considered

Maybe implement fewer of the bullet items.

Additional context

• A clear data model helps prevent bugs such as exportReferencesGraph started including a valid: true field #10485

This path-info topic was previously discussed in meeting #123. Quote:

Previous proposal: Split the output into sections, but no agreement on what the sections should contain.

Minimum set of fields that stay the same on copy (not sure if we want to promise this, but seem to follow the rule) (same set as exportReferencesGraph?)

narHash
narSize
path
references
ca

Group metadata about the build together, e.g. ?

build.deriver
build.time (TBD)

Store-specific state?

store.registrationTime
store.lastVerifiedTime (TBD)
store.signatures
store.ultimate

• @edolstra: Not that many fields that we need to namespace them
• @pennae: Namespacing doesn’t hurt, why not just do it?
• @edolstra: Would break backwards-compat. Can be fine, but needs to be justified

So far, users seem to agree that experimental output can be changed; see also matrix discussion

Priorities

Add 👍 to issues you find important.