YAML 1.1 indicators

[am11]

Some of the v1.1 types are supported by the base parser, while others are not: https://yaml.org/type/. For instance, we can implement !!merge or Merge Key Language-Independent Type in base parser and deprecate MergingParser which only does the copy/paste, and disregards the overriding rules per spec.

These are currently not covered by the official spec test suite, so it would require test coverage of our own.

[aaubry]

This is part of the work that I am doing on Schemas. Yaml 1.1 is just another shema.

[am11]

It is a little bit more involved. Our standard parser (Parser.cs) is tokenizing <<: indicator exactly as the other frameworks with full merge key type support, so we do not need MergingParser.cs for Merge Key Language-Independent Type. Perhaps we can consider deprecating MergingParser altogether right away to avoid confusion.

However, it is the responsibility of deserializer, to merge and override values by the spec.
Currently we do not have alias support in JSON emitter:

YamlDotNet/YamlDotNet/Serialization/EventEmitters/JsonEventEmitter.cs

Lines 36 to 39 in b3cf637

	public override void Emit(AliasEventInfo eventInfo, IEmitter emitter)
	{
	throw new NotSupportedException("Aliases are not supported in JSON");
	}

so it is not easy to visualize the feature parity of Merge Key type. (I did not find any issue tracking it, should we open one?)

The end to end expectation for this example input:

x:
  y: &anchor1
    name: yy
    env:
      a: "a1"
      b: $b
  z:
    <<: *anchor1
    name: zz
    env:
      c: "cc"
      a: "az1"
      b: $b

is:

{
   "x": {
      "y": {
         "name": "yy",
         "env": {
            "a": "a1",
            "b": "$b"
         }
      },
      "z": {
         "name": "zz",
         "env": {
            "c": "cc",
            "a": "az1",
            "b": "$b"
         }
      }
   }
}

In other words, this program should not throw runtime exception: https://dotnetfiddle.net/rk9eWv and output the JSON as shown above.