binutils/binutils: simplify gold dependencies

In preparation of adding a new kernel-type, Yann D. came up
with a change in semantic on binutils/gold availability.

So far, it was architectures' responsibility to declare that
they did support binutils/gold or not. It makes much more sense
that binutils/gold declares its own availability depending on
the current architecture; after all, architectures have no way
to know wether gold supports them, while gold does know it.

Signed-off-by:Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971

 diff -durN gcc-4.4.0.orig/include/libiberty.h gcc-4.4.0/include/libiberty.h

 --- gcc-4.4.0.orig/include/libiberty.h	2008-06-24 03:42:31.000000000 +0200

 +++ gcc-4.4.0/include/libiberty.h	2009-05-27 21:38:24.000000000 +0200

 @@ -595,8 +595,11 @@

  /* Like sprintf but provides a pointer to malloc'd storage, which must

     be freed by the caller.  */

 +/* asprintf may be declared as a macro by glibc with __USE_FORTIFY_LEVEL.  */

 +#ifndef asprintf

  extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;

  #endif

 +#endif

  #if !HAVE_DECL_VASPRINTF

  /* Like vsprintf but provides a pointer to malloc'd storage, which