YAML 1.1-spec boolean pattern matching annoyingly liberal

[alinebee]

Currently YACYAML matches the single-character sequences y/Y and n/N as booleans, along with their more verbose equivalents (true/false, YES/NO, on/off…) This is correct as per the YAML 1.1 spec, which actually specifies y/n as the canonical form for booleans.

However, this is problematic for using single-character sequences as map keys. One common case of this is coordinates: e.g. {x: 0, y: 0 z: 0} will become @{@"x": @0, @YES: @0, @"z": @0 } when parsed.

The YAML 1.2 core spec tightens the boolean pattern to match just true/false, to align with JSON and presumably also to cut out edge-cases like this. I can see the benefit in hewing to 1.1's more liberal schema for unarchiving by default, but I wonder if a YACYAMLKeyedUnarchiverOptions flag to use the stricter 1.2 core schema would be worthwhile.

(In the meantime I've worked around this in my own codebase by removing the single-character alternatives from YACYAMLBoolFalseSet.)