Ensure that YAML fields are sorted

[elezar]

This closes #235

A sample spec would now output as:

---
cdiVersion: v0.3.0
kind: example.com/class
devices: []
containerEdits:
  deviceNodes:
  - path: /dev/foo

instead of:

---
cdiVersion: v0.3.0
containerEdits:
  deviceNodes:
  - path: /dev/foo
devices: null
kind: example.com/class

[klihub]

I'm fine with this if others think this is a good way to go forward.
However, I have a few questions/comments:

• We originally chose to go with the K8s spin on yaml for 2 reasons:
  1. It's explicitly stated design goal is to enable a better way of handling YAML when marshaling to and from structs which is pretty much the only thing we use YAML for in CDI. This reference given here provides the original justification/reasoning behind the (predecessor to the) sigs.k8s.io implementation instead of using the stock golang one, and I simply don't know if these are now irrelevant/invalid for gopkg.in/yaml.v2.
  2. As working in the K8s and runtimes domains, we typically deal with YAML via the sigs.k8s.io package and therefore I think any potential behavioral differences will catch us by surprise.
• Since gopkg.in/yaml.v2 does not reuse the JSON struct tags, can we have some linter verifying that we always have either neither or both JSON and YAML tag explicitly defined ?

[elezar]

Thanks for the points that you raised, @klihub. The main motivation for struct-based ordering is the human readability implied by the ordering. Note that the underlying yaml implementation is still gopkg.in/yaml.v2.

Let me take some time to better address / answer your questions.

[klihub]

Thanks for the points that you raised, @klihub. The main motivation for struct-based ordering is the human readability implied by the ordering.

Sure, I understood that and I'm all for it. Just wanted to make sure that nothing hits us by surprise as a side-effect.

[elezar]

@klihub @bart0sh I have updated the implementation to only switch to ordered YAML when outputing the files. This means that for the consumer (containerd, cri-o, etc) workflow we have not changed anything. Another option would be to add a non-default "ordered" option to the producer API from #233 so that we don't have to change the default behaviour at all.