Consider adding spec fields describing the config source and generator

Feature Request

Environment

Any

Desired Feature

Consider adding spec fields describing where a config came from: the corresponding human-readable source file and the tool used to convert it into an Ignition config.

The purpose of these fields is to assist users in determining the source of an Ignition config and what bugs may have existed in the tool used to generate it. They are explicitly not to be used by Ignition to work around bugs in generator tools.

Example spec fragment

The data model below is intentionally simplistic, e.g. it does not handle multiple source files or multiple generator tools. We could expand the model if that seems useful, but I didn't want to overdo it.

• ignition (object): metadata about the configuration itself.
  • config (object): options related to the configuration.
    • origin (object): information about the human-readable source file for the configuration.
      • identifier (string): a URI referring to the source file. This is not resolved by Ignition.
      • hash (string): the hash of the source file, in the form <type>-<value> where type is sha512.
    • generator (object): information about the software that generated the configuration.
      • software (string): a URL referring to the software, such as a website or source code repository.
      • version (string): the version of the software. This does not need to be a semantic version number and has no semantics.

Start by reviewing the configuration specification and the example metadata model in this issue. Determine where Ignition defines and validates spec fields, then clarify the model for source identifiers, hashes, generator software, and versions. Done means the agreed fields are represented consistently in the spec and their behavior is covered by the relevant validation or specification tests.