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

CT_LOCAL_TARBALLS_DIR="${HOME}/src"

CT_SAVE_TARBALLS=y

CT_LOG_EXTRA=y

CT_ARCH_CPU="405"

CT_ARCH_TUNE="405"

CT_ARCH_FLOAT_SW=y

CT_ARCH_powerpc=y

CT_TARGET_VENDOR="405"

CT_KERNEL_linux=y

CT_KERNEL_V_2_6_31_14=y

CT_BINUTILS_V_2_19_1a=y

CT_BINUTILS_FOR_TARGET=y

CT_CC_V_4_3_2=y

CT_CC_LANG_FORTRAN=y

CT_CC_LANG_CXX=y

CT_CC_LANG_JAVA=y

CT_LIBC_glibc=y

CT_LIBC_GLIBC_V_2_9=y

# CT_LIBC_GLIBC_FORCE_UNWIND is not set

CT_LIBC_GLIBC_USE_PORTS=y

CT_DEBUG_dmalloc=y

CT_DEBUG_duma=y

CT_DEBUG_gdb=y

CT_GDB_NATIVE=y

CT_GMP_V_4_3_2=y

CT_MPFR_V_2_4_2=y