Escape characters that YAML cannot carry literally (#1846)

YamlEmitter only routed a string into YamlEscaper when it held a
character below 0x20, so 0x7F, the C1 block, U+2028 and U+2029 went out
as plain scalars. They are not `c-printable` (YAML 1.2 spec 5.1), and
NEL, LS and PS are line breaks in YAML 1.1, so the rendered document is
either rejected or silently split by a reader.

The escapes added in #1165 for 0x85, 0xA0, U+2028, and U+2029 could only
fire when some other character happened to open that gate. Share one
predicate between the two sites that decide, and give 0x7F-0x9F the
8-bit escape they lack.

pkl-core/src/test/files/LanguageSnippetTests/input/api/yamlRendererStrings.yml.pkl

@@ -39,6 +39,17 @@ h4 = "one\rtwo"
 h5 = "\u{7}"
 h6 = "one\u{7}two"
 
+// characters outside `c-printable` (YAML 1.2 spec 5.1), and YAML 1.1 line breaks
+h7 = "\u{7f}"
+h8 = "one\u{7f}two"
+h9 = "one\u{80}two"
+h10 = "one\u{85}two"
+h11 = "one\u{9f}two"
+h12 = "one\u{2028}two"
+h13 = "one\u{2029}two"
+h14 = "one\u{fffe}two"
+h15 = "one\u{ffff}two"
+
 // control characters in multiline strings
 i1 = "one\ttwo\nthree"
 i2 = "one\rtwo\nthree"

pkl-core/src/test/files/LanguageSnippetTests/output/api/yamlRendererStrings.yml

@@ -53,6 +53,15 @@ h3: "\r"
 h4: "one\rtwo"
 h5: "\a"
 h6: "one\atwo"
+h7: "\x7f"
+h8: "one\x7ftwo"
+h9: "one\x80two"
+h10: "one\Ntwo"
+h11: "one\x9ftwo"
+h12: "one\Ltwo"
+h13: "one\Ptwo"
+h14: "one\ufffetwo"
+h15: "one\ufffftwo"
 i1: "one\ttwo\nthree"
 i2: "one\rtwo\nthree"
 i3: "one\atwo\nthree"