Multiple merge

[moskyb]

Fixes #966

This PR adds the capability to decode multiple merge nodes on a given document - eg, the document

one: &one
  a: 1
  b: 2

two: &two
  b: 3
  c: 4

merged:
  <<: *one
  <<: *two

will now decode to

map[string]any{
  "a": 1
  "b": 3
  "c": 4
}

where previously, it would have returned an error saying that the merged mapping had a duplicate key <<.

While this behaviour isn't in the YAML spec (the blessed way to do multiple merges is <<: [*one, *two]), it's also not disallowed by it, and many yaml libraries for other languages - notably Python's pyyaml and Ruby's psych, which is backed by libyaml - do support this behaviour.

Multiple issues (#966, #918) on this have been raised on this repo before, which leads me to believe that using multiple merge keys is a relatively common expectation to have for a yaml library.

[pda]

It would be good to match how other applications of libyaml¹ handle https://yaml.org/type/merge.html by supporting multiple merge keys like this 👍🏼

It's true that the Merge Key spec shows passing an array of anchors to achieve this result, rather than multiple merge keys in a single mapping, but the fact that it's supported in other popular languages, and therefore used out in the wild², makes this an interoperability issue.

¹ While go-yaml isn't strictly an application of libyaml, it is a Go port of libyaml plus the Go application/integration thereof, so I think it's the same category.

² I work with @moskyb and we have examples of multiple customers using the multiple-Merge-Key style.

[pda]

We could probably hoist this above the for j := … loop, and say:

if isMerge(ni) {
  // Merge keys ("<<") are discarded during processing, so don't need to be unique.
  continue
}

[derbylock]

Can we release it?