Non-ASCII characters (like Unicode "é", represented as two bytes \xC3 \xA9 in
the UTF-8--encoded source file, and presumably passed trhough unchanged by
compilers into the resulting string literal object) in the OUString "literal"
ctor trigger a SAL_WARN_IF in rtl_uString_newFromLiteral, but are copied
"verbatim" into the resulting OUString, which will thus contain UTF-16 code
units \x00C3 \x00A9 (if char is unsigned) resp. \xFFC3 \xFFA9 (if char is
signed).

That assertXPathContent shall indeed match such an odd OUString value looks
suspiciously like a bug elsewhere, papered over by a broken test.  To be
investigated.

Change-Id: I07c995ad0e17235c214d7630fb34e8ef35d5ad30