to-do: investigate the viability of ParseOptions and StringifyOptions in @std/yaml

[iuioiua]

These interfaces have a lot of options, and each added option means more engineering overhead for both users and maintainers. We should go over each option and only keep the ones that have sufficient justifications for existing.

ParseOptions:

• legacy (removed in BREAKING(yaml): remove ParseOptions.legacy option #5229)
• listener (removed in BREAKING(yaml): remove listener option from parse() and stringify() #5224)
• filename (removed in BREAKING(yaml): remove filename option from parse() and stringify() #5223)
• schema
• json (renamed to allowDuplicateKeys in BREAKING(yaml): rename ParseOptions.json to ParseOptions.allowDuplicateKeys #5282)
• onWarning (reworked in refactor(yaml): remove first argument from ParseOptions.onWarning #5284)

StringifyOptions (currently DumpOptions but to be updated in the next release):

• indent
• noArrayIndent
• skipInvalid
• flowLevel
• styles
• schema
• sortKeys
• lineWidth
• noRefs
• noCompatMode (removed in BREAKING(yaml): remove StringifyOptions.noCompatMode #5233)
• condenseFlow

[iuioiua]

ParseOptions.json allows parse() to behave similarly to JSON.parse(), in that duplicate keys are overwritten rather than throwing errors. This goes against the YAML 1.2 spec, which states that duplicate keys should cause errors (see here and here). Do we want to remove the ability to have this functionality (AKA remove ParseOptions.json) or keep it? @kt3k

[iuioiua]

This has been completed in a series of already merged PRs.