daf5137 fixed a bug where the failure message would not be printed
correctly if it included values subject to shell variable expansion
(e.g. "$FOO") by quoting the limit string for the heredoc the message
("cat <<'EOF'"). However, it still left an issue if that limit string
appeared on its own line in a message, which would happen if a compared
value included "\nEOF\n". (Plausible if the function under test
generated shell script code.) This could be worked around by choosing
a more unusual string, but that remains an odd implementation detail.
Instead, the shell implementation could use the same path of splitting
the output into lines, echoing each line, and backslash-escaping each
character.

The previous code also did not split the error output into lines
correctly if individual failure messages contained newlines (which
could happen when comparing values where at least one was a string
containing a newline; the code that generates the error message
converts with "%s" (str)). This matters if those lines are joined
with something other than "\n", which was the case in the Windows
implementation (and now is the case with both).

The Windows implementation also did not avoid variable expansion
by escaping "%" as "%%" if the error message included "%".