Workaround Linux NTPL lock elision bug.

Workaround Linux NTPL lock elision bug.

glibc 2.19 on Linux x86-64 platforms includes support for lock elision,
by using Intel's TSX support when it is available.  Without modifying an
application this converts suitable critical sections that use mutex into
transactional memory critical sections.  See http://lwn.net/Articles/534758/
If a problem occurs that means that transactional memory can't be used, such
as a system call or buffer overflow, the pthreads implementation will catch
this error and retry the critical section using a normal mutex.

I noticed that since upgrading glibc that programs using Boehm GC crash, one
of these crashes was an assertion that the owner field of a mutex was
invalid.  The assertion was generated by the pthreads implementation.
I believe that there is a bug in glibc that when a mutex cannot be used
safely for transactions that some series of events causes it's owner field
to be set incorrectly (or cleared when it shouldn't be).

I've found that I can work around this problem by having Boehm GC use an
error checking mutex, which I believe doesn't use lock elision and in my
testing doesn't crash.

XXX: This work-around mostly works except for linking the feature detection
in configure.ac to the conditional compilation in pthread_support.c as there
isn't an obvious way to make it work for automake and Makefile.direct.
Could I have some help updating the build system please?

include/private/pthread_support.h:
pthread_support.c:
    Define GC_setup_mark_lock()  This procedure creates the lock specifying a
    pthread_mutexattr_t structure.  This is used to disable lock elision on
    Linux with glibc 2.19 or greater.

configure.ac:
    If we're using Linux then check for the gnu extensions required to
    identify the version of glibc at runtime.

misc.c:
    Call GC_setup_mark_lock() when initialising the collector.