...as emitted by at least GCC 8.2 with --enable-optimized, e.g. at:

> In file included from include/rtl/ustring.hxx:37,
>                  from include/cppuhelper/factory.hxx:26,
>                  from unoxml/source/rdf/librdf_repository.hxx:24,
>                  from unoxml/source/rdf/librdf_repository.cxx:20:
> include/rtl/string.hxx: In static member function ‘static std::shared_ptr<{anonymous}::librdf_TypeConverter::Node> {anonymous}::librdf_TypeConverter::extractNode_NoLock(const com::sun::star::uno::Reference<com::sun::star::rdf::XNode>&)’:
> include/rtl/string.hxx:294:27: error: ‘*((void*)(& type)+8).rtl::OString::pData’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>          rtl_string_release( pData );
>          ~~~~~~~~~~~~~~~~~~^~~~~~~~~
> unoxml/source/rdf/librdf_repository.cxx:2094:30: note: ‘*((void*)(& type)+8).rtl::OString::pData’ was declared here
>      boost::optional<OString> type;
>                               ^~~~

This appears to be a common pattern of false positives with uses of
boost::optional, common enough to disable the warning globally for affected
compilers, even if there would also be useful findings by that warning (e.g.,
<https://gerrit.libreoffice.org/#/c/66619/> "Fix -Werror=maybe-uninitialized").

I didn't bother to file a GCC bug for the reproducer used in configure.ac,
<https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=maybe-uninitialized>
already shows lots of open bugs in that area, and the documentation at
<https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html> states that
"GCC may not be able to determine when the code is correct in spite of appearing
to have an error."

(Clang appears to not support -Wmaybe-uninitialized at all, so exclude it from
the configure.ac check, to not have the check's failure result in an unsupported
-Wno-maybe-uninitialized end up on the compiler command line.)

Change-Id: Ifb9ca4c342750eae54f7e1a01506101310484c7e
Reviewed-on: https://gerrit.libreoffice.org/66621
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>