--enable-stack-protector for glibc, v3

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

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

Still no changelog citing bug 7065: I'm not confident enough that things won't
change, but I'd be more confident if someone could look at patch 13 in this
series and tell me why on earth it's even necessary (which it definitely is).

It's not rebased and is still against glibc head as of a week 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
--without-stack-protector
--enable-stack-protector=no

Tested with --enable-stack-protector, --enable-stack-protector=strong and
--enable-stack-protector=all on sparc{32,64}-pc-linux-gnu.  No failures are
observed that are not also observed on an unpatched glibc with the same flag
combinations, other than localplt (due to the new __stack_chk_fail PLT, which
I'd suggest is desirable: it seems like something people might reasonably want
to interpose, and interposing it will have no performance implications).

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.


Overview of changes in this posting:

 - eliminated most most ifdefs on $(have-ssp) using a new $(no-stack-protector)
   variable.

 - cleaned up the changes to elf/Makefile in patch 6, using a macro to reduce
   redundancy and bringing all the -fstack-protector-elision code together
   rather than having the rtld and static-libc portions separated by hundreds
   of lines.

 - wrapped a couple of long lines (the only remaining ones are in configure.ac
   and are probably not rewrappable).

Remaining mysteries:

 - In patch 13, I have no understanding of why __pthread_mutex_unlock_usercnt()
   and __pthread_mutex_cond_lock_adjust() are special: yes, they're called
   directly from assembler, but that shouldn't be a problem: -fstack-protector
   doesn't change the function-call ABI!  Nonetheless, it *is* a problem, and
   this is definitely necessary.  I just don't know what *else* might be
   necessary.  It is almost certain that this sort of thing will be the primary
   problem when making other arches happy with this change (it was the only real
   thing I had to do with sparc, in patch 14, -fno-sparc-protecting the
   sigreturn handler, and just as with the pthread functions I don't really know
   why -- but it is clearly necessary.)

   It *is* clear why we have to -fno-stack-protect setjmp/sigjmp.c: the thing is
   *sibcalled* from assembler, and the assembler has pre-built a stack frame,
   complete with lack of canary, so setjmp/sigjmp.c had better not introduce
   one.  (Even in the absence of local variables, -fstack-protector-all will add
   a canary to the lone function in that file.)