Garbage in, garbage out?

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
Introduce rtl::OUStringLiteral1

...to use single ASCII character literals "more directly" in the OUString API
(instead of having to go via an intermediary OUString ctor call).  Especially
useful for character literals that are defined as const variables or via macros
("direct" uses of character literals in the OUString API can often simply be
replaced with single-character string literals, for improved readability).

(The functions overloaded for OUStringLiteral1 are those that are actually used
by the existing LO code; more could potentially be added.  The asymmetry in the
operator ==/!= parameter types is by design, though---writing code like

  'x' == s

is an abomination that shall not be abetted.)

Change-Id: Ic5264714be7439eed56b5dfca6ccaee277306f1f
rtl::OUStringLiteral to the rescue

...for cases where ? "a" : "bb" does not work, as well as to work around the
MSVC bug for cases like ? "a" : "b".

Change-Id: Id404716047aca5cc81440f291616d92365379b8f