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_bash@@

 # What we need:

 #  - the .config file

 # Parse the tools' paths configuration

 . "${CT_LIB_DIR}/paths.sh"

 # We'll need the stdout later, save it

 exec 7>&1

 # Parse the common functions

 . "${CT_LIB_DIR}/scripts/functions"

 # Don't care about any log file

 exec >/dev/null

 rm -f "${tmp_log_file}"

 # Parse the configuration file

 . .config.2

 # Parse architecture and kernel specific functions

 . "${CT_LIB_DIR}/scripts/build/arch/${CT_ARCH}.sh"

 . "${CT_LIB_DIR}/scripts/build/kernel/${CT_KERNEL}.sh"

 # Build CT_TARGET

 CT_DoBuildTargetTuple

 # All this for this single echo... :-( Sigh, I'll have to re-arrange things...

 echo "${CT_TARGET}" >&7