--enable-stack-protector for glibc, v6

[Nix <nix at esperi dot org dot uk>]

This is version 6 of the stack-protected glibc patch, incorporating all review
comments to date (unless I missed some).

It's not rebased and is still against glibc head as of a few weeks ago,
a5df3210a641c17.

Tested with these flag combinations on {i686,x86_64)-pc-linux-gnu:

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

Tested with with these flag combinations on sparc{32,64}-pc-linux-gnu:

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

Tested with these flag combinations on armv7l-unknown-linux-gnueabihf (it
happened to have GCC 4.8, so -strong wasn't available):

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

No failures are observed that are not also observed on an unpatched glibc with
the same flag combinations.

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 11 is
in Adhemerval's name, but obviously there's no assignment problem there either.)

The only remaining question I really have is what to do instead of patch 13,
which I really do expect to be rejected.  Another configure argument to set the
stack-protection level of externally-facing components, perhaps, or simply a
wiring-in that if --enable-stack-protector is not passed, that -fstack-protector
is passed in for these external components anyway?  What I do think is that the
level set via --enable-stack-protector should be a minimum: that libresolv, nscd
et al should never be protected *less* than libc.so and the rest are.  Patch 13
was a nice simple way to do that, but it is probably *too* simple...

Overview of changes in this posting:

 - Quoting and shell-portability-sanity fixes in configure.ac
   [Review comments from Mike Frysinger and Andreas Schwab.]

 - No longer bother checking for __attribute__((__optimize__)): it is supported
   on all GCC versions we support, and -fno-stack-protector has worked in
   __attribute__((__optimize__)) for longer than that as well.
   [Review comment from Mike Frysinger.]

 - Only open-code the memcpy() in statically-linked TLS initialization if stack
   protection is in use and we don't have an arch-specific inline asm
   implementation that we can fall back on (as x86-32 does, and no-one else).
   [Review comment from Mike Frysinger.]

 - Move IREL application in static binaries up above the TCB initialization:
   this puts it back in its old relative position with respect to all that
   machinery, so you can call ifunced things like memcpy() when initializing
   the TLS -- as long as stack-protection is disabled, since we don't stack-
   protect memcpy().  (The only difference between the old and new static
   startup paths is now that the TLS and stack-protector canary are set up
   before the oscheck hook is called rather than afterwards.)
   (Needed for the above.)

 - Rather than linking libc_nonshared.a to libc.so in order to get
   __stack_chk_fail_local, compile a new debug/libc-stack_chk_fail_local.c as
   shared-only and link it in, which also means that we don't need to redirect
   __stack_chk_fail -> stack_chk_fail_local in the static libcs.  Consider
   __stack_chk_fail_local to be as ignorable as __stack_chk_fail when figuring
   out what symbols are needed by rtld.
   [Review comment from Andreas Schwab.]