Reliably determine whether thread-local storage is available

The configure script contains a crude test that determines whether the
__thread keyword is broken on this particular Linux distribution. However,
the code is problematic as it is run on non-linux operating systems and it
assumes that dynamic linking is availabe. However, my operating system has
perfectly usable thread-local storage and only static linking, causing this
code to mistakenly believe the __thread keyword is broken.

This commit runs the test only on Linux systems. However, an even better
test would check whether dynamic linking works in the first place before
testing whether dynamin linking and thread-local storage is broken.
Remove Mono_Posix_Syscall_utimes_bad

Welcome to the world of tomorrow! It's been almost a decade since this was
made obsolete in 2005. Nothing uses this function any longer. Additionally
it is completely broken as utimes takes a pointer to an array with two
timevals, but the code passes only a pointer to a single timeval.
define MONO_ARCH_NOMAP32BIT if !defined(MAP_32BIT)

This was a huge source of pain with a hidden solution. Assuming that mmap
always returns below 2 GiB on 64-bit systems is absolutely crazy, unless
extra effort is taken to ensure this is true. Some operating systems provide
the ugly hack MAP_32BIT that guarantees this and Mono is able to use this
mmap flag if it is available. However, if it is unavailable and the
operating system is not specifically listed as not having MAP_32BIT, then
Mono #defines it to 0 and pretends it works. This leads to mysterious
crashes and assertion failures inside the JIT engine. Mono is already able
to deal with a full 64-bit mmap, but only if MONO_ARCH_NOMAP32BIT is
defined. Rather than explicitly listing the sane operating systems in an
header, MONO_ARCH_NOMAP32BIT should be automatically defined if MAP_32BIT is
not available.
Restore the null garbage collector

I had to use the null garbage collector due to boehm being troublesome. The
code appears unmaintained but I can see a recent git commit enabled support
again. However, I had to do more than that to get it working. I'm really not
sure how semantically correct this is and it needs review from an expert in
how threads and garbage collection interplay in Mono. It seems very odd that
various attributes (such as its short id) about the main thread is
initialized as a side effect of initializing the garbage collection. The
mono_thread_info_attach was needed to prevent a crash.