Make it easier to gate core code behavior on the config spec version

We've landed some features lately which broadened the behavior of existing fields (e.g. #968, #969). Because these were implemented in core code, it wasn't easy to limit the new features to the current experimental spec, so we supported the feature across all config versions. However, this is a trap: users might write configs that work with the current Ignition version, then pass those configs to an older Ignition version that supports the same spec but doesn't support the feature in question. We should consider plumbing the spec version more broadly through the codebase so it's easier to limit features in core code to new specs only.

There's another side to this argument, of course. We don't want to version-gate bugfixes, and a bug can make a feature just as unusable as if it was outright missing. It's not clear how often we'd want to intentionally gate functionality in this way, vs. expecting the user to know the limits of the Ignition versions they're targeting.

Start by tracing how the config spec version is represented and passed through core code; the issue does not name specific files, tests, or entry points. Review the examples in #968 and #969, then determine where version-gating could apply without gating bug fixes. Done would require an agreed scope and implementation plan for plumbing the spec version.