scripts/libc: do not build add-ons by default

Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.

This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.

This patch disables the building of all add-ons in that case.

It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

 File.........: 7 - Contributing to crosstool-NG.txt

 Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>

 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5

 Contributing to crosstool-NG  /

 _____________________________/

 Sending a bug report |

 ---------------------+

 If you need to send a bug report, please send a mail with subject

 prefixed with "[CT_NG]" with to following destinations:

     TO: yann.morin.1998 (at) anciens.enib.fr

     CC: crossgcc (at) sourceware.org

 Sending patches |

 ----------------+

 If you want to enhance crosstool-NG, there's a to-do list in the TODO file.

 Patches should come with the appropriate SoB line. A SoB line is typically

 something like:

    Signed-off-by: John DOE <john.doe@somewhere.net>

 The SoB line is clearly described in Documentation/SubmittingPatches , section

 12, of your favourite Linux kernel source tree.

 For larger or more frequent contributions, mercurial should be used.

 There is a nice, complete and step-by-step tutorial in section 'C'.