--enable-stack-protector for glibc, v10

[Nix]

Here, as promised, is version 10 of the stack-protected glibc patch,
incorporating all review comments to date (unless I missed some).

Like the last, it's against glibc head as of Sat Nov 26, bf469f0ce98.

Tested with these flag combinations on {i686,x86_64)-pc-linux-gnu (with GCC
6.2.1-20161118, binutils 2.27.0.20160920, and kernel headers for v4.7.4):

--enable-omitfp --enable-stack-protector=all
--enable-stack-protector
--enable-stack-protector=strong
--enable-stack-protector=all
--enable-stackguard-randomization --enable-stack-protector=all
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector=strong
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector=all
--disable-stack-protector
--enable-stack-protector=no

(The only skipped tests were the AVX math tests, since the test machine is not
AVX-capable.)

Tested with with these flag combinations on sparc{32,64}-pc-linux-gnu (with GCC
4.9.1-20140922 (a bit old, sorry), binutils 2.24, and kernel headers for
v4.1.12):

--enable-stack-protector
--enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=all
--disable-stack-protector
--enable-stack-protector=no

Tested with these flag combinations on armv7l-unknown-linux-gnueabihf (with GCC
4.8.5-2ubuntu1~14.04.1 (so -strong isn't available), binutils 2.24, and kernel
headers for v3.13.11):

--enable-stackguard-randomization --enable-stack-protector
--enable-stackguard-randomization --enable-stack-protector=all --enable-omitfp
--disable-stack-protector
--enable-stack-protector=no

No failures are observed that are not also observed on an unpatched glibc with
the same flag combinations, saving only the usual intermittent localedata/wcs*
tests, an intermittent failure of the assertion in stdlib/tst-makecontext on
sparc32, and a consistent failure of posix/tst-spawn2: but these are mostly
likely spurious, other than posix/tst-spawn2, but I would completely believe
that a buffer overrun there is not spurious at all. The makecontext assertion
seems likely to depend on the behaviour of the installed libgcc_s.so...)

On the copyright assignment front, I am informed that Oracle has a blanket
assignment on file for glibc work, so I don't need to do anything.  (Patch 8 is
in Adhemerval's name, but obviously there's no assignment problem there either.)

Overview of changes in this posting:

 - Add back patch #1 in the series, the configury changes, accidentally dropped
   in the previous posting: whoops!

 - Revamp the __stack_chk_fail PLT-avoidance machinery to use strong_alias, like
   everything else: much thanks to Florian, who noticed that the hack I was
   using was problematic and provided tireless guidance in getting it fixed;
   debug/libc-stack_chk_fail_local.c is gone; there is not very much left of
   Adhemerval's original patch, but I'm leaving his name on it because it seems
   presumptuous to remove it; there are no __stack_chk_fail PLT bypasses on any
   platforms I have access to any more

 - As part of this, #define STACK_PROTECTOR_LEVEL=0 in non-stack-protected files
   within an otherwise stack-protected glibc, and when glibc is not
   stack-protected at all.

 - Explicitly pass -fno-stack-protector when glibc is not compiled with
   --enable-stack-protector: this prevents compiler-inserted __stack_chk_fails
   from being generated when glibc is not set up for PLT-bypassing them (will
   need tiny revisions if --enable-stack-protector becomes the default, but that
   time is not yet)

 - Drop some more libc_cv_predef_stack_protector checks that landed since my
   last series

 - Several tests were declaring that they needed to be compiled with
   $(no-stack-protector) when this is no longer true

 - Move the tests that were in csu/ (most of which were barely related to the
   code in csu/) into misc/ instead, so the -fno-stack-protection applied to the
   static-libc csu code does not cover the tests as well

 - Compile two PIE tests (tst-quad[12]pie.c) with -fPIE, since they are being
   linked with it and when stack-protection is enabled they suddenly contain
   external symbol references for the first time, which will result in the wrong
   relocation if the compiler does not know PIE is in use