When UnwrapScalar is enabled (the default for yaml output), the yaml
encoder writes node.Value verbatim as a bare line. Any string whose
content is itself a valid YAML mapping, sequence, or alias then round
trips as that container instead of as a string. For example, the input
document `"this: should really work"` previously re-emitted as the bare
line `this: should really work`, which the next reader parses as a one
key map, destroying the original scalar. The same problem surfaces
whenever a multiline string literal happens to contain `key: value`
lines, which is the form the bug report uses for its second reproducer.
Guard the fast-path by re-parsing node.Value with yaml.v4: if the bare
form decodes to a non-scalar, fall through to the regular encoder so it
can apply the quoting style required by the YAML spec. The check is
limited to `!!str` nodes and to structural reinterpretations, so tag
expressions such as `!!int` and plain strings that re-read as integers,
booleans, or nulls are unaffected. An unparseable value (e.g. one
containing NUL) stays on the fast-path so downstream NUL-aware writers
still see the raw bytes.
Updates the base64 "decode yaml document" scenario whose expected
output was `a: apple\n` bare; it is now emitted as a block literal,
which round-trips back to the same string.
Reproducer:
```
printf '"this: should really work"\n' | yq -p yaml -o yaml
```
Before this fix the second run of yq parses the output as a map;
after, it remains the original string.
Fixes#2608
