Tracking issue for YAML 1.2 emitter support

[am11]

YDN v8.1.1+ support scanning and parsing of YAML 1.2 documents by the spec. This is indicated in the repo's README.

This issue is to track support for YAML 1.2 for emitter and (JSON) serializer.

As a prerequisite cleanup, I propose to refactor some bits for better diagnosability and facilitating emitter spec testing:

• [x] Move libyaml event stream in its own emitter, so existing parser spec test runner and yaml-runtime can share it: https://github.com/aaubry/YamlDotNet/blob/7f8c2992ee2b3e627e5719ba4d892a7ce209c68a/YamlDotNet.Test/Spec/SpecTests.cs#L116
• [x] Extract spec suite directory discovery into utilities.
• [x] Rename SpecTests.cs to something like ParserSpecTests.cs.

after that:

• [ ] Add EmitterSpecTests.cs with execution, assertions and ignore lists.

After the initial bootstrapping of emitter test runner, add the list of failing tests below this line for tracking.

TODO: add list

[aaubry]

This looks good. FYI, I'm currently working on implementing schemas, based on the 1.2 spec. This may be relevant for this work.

[am11]

Cool, looking forward to it. 🙂 I haven't' looked much deeper but I think we have some spec tests validating schema on emitter side.

After the #485 refactoring, I will switch to working on emitter spec tests execution.

[bootzin]

How's the progress on this?

[am11]

@bootzin, spec suite for emitters was configured in master branch, such that anyone can contribute to improve the coverage and de-ignore the related specs. https://github.com/aaubry/YamlDotNet/blob/e32f92ed079c1b62fdd949b37c23db047649934c/YamlDotNet.Test/Spec/SerializerSpecTests.cs#L39

My last work in progress for emitters was a scenario which we do not currently support (for 1.1 either): "end-to-end (roundtripable) mapping of anchors". We have added support for anchor deserialization in #490. However, for serialization, preserving anchor E2E becomes quite complicated and expensive in terms of performance (hint; reflection and bookkeeping of complex object graphs), code complexity and maintenance.. unless we add support for C# 9 code generators or some such.

Also, I am not sure how valuable is it in real world? One of the Ruby based YAML library used to have this kind of anchor serialization support, but they removed it (probably it was deemed not worth the effort?)