Reference multiple YAML objects from one destination

[LucasPickering]

From @erhhung in this comment:

Slumber intentionally removed support for YAML << operator and opted for $ref. However, the latter doesn't support the feature that I find useful: multiple merges (e.g. <<: [*common_constants, *homelab_constants, common_templates]) because $ref can only refer to a single value and having multiple $ref keys is obviously not allowed.
As my API requests grow, I need to group related functionality in their own sections (or even separate "environment" files) and compose them under my profiles..data.

We should support this use case. We could:

• Add back the merge syntax. I don't think we would need the anchor, alias syntax, as you could merge multiple $ref objects:

data: 
  <<: [{$ref: "#/ref1"}, {$ref: "#/ref2"}]

• Support multiple $ref keys in one object. I think it's possible with the saphyr parser but I'm not sure, need to look into it more. It does trigger a lint error with the YAML language server I use in zed, so that sucks.

[erhhung]

<<: [{$ref: "#/ref1"}, {$ref: "#/ref2"}]

I haven't seen such syntax before as it's not shown as a use case in the 1.1 Spec, so even if you can make it work in Slumber, I'd be wary of de/serialization through other tools.

# test.yaml
foo: &foo
  x: 1
  y: 2
bar: &bar
  x: 3
  z: 4
data1:
  <<: [*foo, *bar]
data2:
  <<: [{$ref: "#/foo"}, {$ref: "#/bar"}]

$ yq --yaml-fix-merge-anchor-to-spec . test.yaml
foo: &foo
  x: 1
  y: 2
bar: &bar
  x: 3
  z: 4
data1:
  !!merge <<: [*foo, *bar]
data2:
  !!merge <<: [{$ref: "#/foo"}, {$ref: "#/bar"}]

# you'd have to expand the $ref's BEFORE !!merge for this to work,
# and if the YAML round trips through JSON, it wouldn't even work
$ yq --yaml-fix-merge-anchor-to-spec -oj . test.yaml
{
  "foo": {
    "x": 1,
    "y": 2
  },
  "bar": {
    "x": 3,
    "z": 4
  },
  "data1": {
    "x": 1,
    "y": 2,
    "z": 4
  },
  "data2": {
    "$ref": "#/foo"
  }
}

(with <<: [*foo, *bar], you would think that keys in bar would override keys in foo as last-one-wins is the common rule, but clearly yq is following spec, which says "Keys in mapping nodes earlier in the sequence override keys specified in later mapping nodes.")