Use gnulib's C++ namespace support

In the default "C" mode, gnulib's replacements are called rpl_foo, and
then gnulib creates defines that rewire the replaced symbols, like:

  #define printf rpl_printf
  #define open rpl_open
  #define close rpl_close
  ...

This is a bad idea in C++.  It prevents use of such symbols as class
methods, in other namespaces, etc..  C++'s standard libraries #undef's
C macro-like functions for the same reason (it's required by the C++
standard, I believe).  So redefining these symbols as macros likely
causes conflicts with C++ system headers.  See example of example that
here <https://sourceware.org/ml/gdb-patches/2016-11/msg00156.html>,
though in that case the culprit was Python.

gnulib has an way to address this, by putting the replacements in some
namespace instead, and avoiding use of macros to create the
replacements.  See:
  https://www.gnu.org/software/gnulib/manual/html_node/A-C_002b_002b-namespace-for-gnulib.html

This patch makes GDB use that feature.  The namespace is enabled in
common-defs.h, with:

  --- c/gdb/common/common-defs.h
  +++ w/gdb/common/common-defs.h
  @@ -20,6 +20,8 @@
   #ifndef COMMON_DEFS_H
   #define COMMON_DEFS_H

  +#define GNULIB_NAMESPACE gnulib

The rest of the patch is just using "gnulib::" where necessary.  Any
spot needing adjustment is found by the compiler, with:

  .../src/gdb/cli/cli-dump.c: In function ‘void restore_binary_file(const char*, callback_data*)’:
  .../src/gdb/cli/cli-dump.c:554:13: error: call to ‘fread’ declared with attribute warning: The symbol ::fread refers to the system function. Use gnulib::fread instead. [-Werror]
     if (fread (buf.get (), 1, len, file) != len)
	       ^
  cc1plus: all warnings being treated as errors

We can choose any namespace name.  "gnulib" just looks natural to me.
Maybe picking a 3-letter namespace, like "glb" [1] would make it
easier to switch some symbol to the std namespace later on, without
requiring reindenting multi-line statements/expressions.  OTOH, being
explicit is probably clearer.  So dunno.

This may look a bit ugly at first.  (that's how it looked to me).  But
it grows on you over time.  :-) For one, it makes is much more obvious
where the replacements are being used.  And, it's likely that as we
C++fy more code, many of these gnulib:: references disappear behind
higher-level abstractions.  So nowadays I see this explicitness as a
good thing, actually.