modify for VPATH builds
[HttpWebRequest] Add timeout tests that cover BNC#317553 (ximian #74177)

The pull-request that was merged [1] intending to fix BXC#1183 [2] was
later reverted [3] because it broke a scenario that wasn't covered by tests.

This commits creates a couple of tests that cover this scenario (which was
implemented back in 2005 [4]) so that we are sure that any further proposed
fixes for bug 1183 [2] don't cause any regression in this area.

[1] https://github.com/mono/mono/commit/8c2167d52cb9acf9582647ebb5f99c92d9127fbd
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=11833
[3] https://github.com/mono/mono/commit/14f0405443693ec2586e73e4b3746134046210d5
[4] https://bugzilla.novell.com/show_bug.cgi?id=317553
Merge pull request #617 from knocte/httpwebrequest_playground

[HttpWebRequest] Add timeout tests that cover BNC#317553 (ximian#74177)
[configure] Use the preprocessor to determine the target FPU on ARM.

This is needed for a number of reasons:

1. Runtime detection of the target FPU is very hostile towards
   cross-compiling. We'd previously only pick up an FPU if we're
   compiling directly on the target device.
2. The runtime detection logic would attempt to use FP instructions
   regardless of whether the toolchain is actually configured for
   it. That means we could end up detecting an and using an FPU
   when the entire system is actually soft float, i.e. P/Invoke
   blows up.
3. The previous detection logic is never what distro packagers
   want because one build server could just happen to have an FPU
   even though the package is being built for soft float (armel).
4. We previously invoked 'gcc' explicitly, which is of course wrong
   when a non-GCC compiler is being used, or the compiler has a
   completely different executable name.

We now check preprocessor definitions to detect the FPU in use. This
works with cross-compilation, respects the toolchain's configuration,
and works when non-GCC compilers are being used. It also means distro
packagers can eliminate some downstream patches they previously used
to sanitize the FPU detection logic.
Always restore extension methods candidates after each run
now we (can) build Rx assemblies for mobile by *.sln in our mono/rx.git, so remove them from Makefile.
Remove obsolete 32 bit s390 backend.
Support a MONO_ARCH_HAVE_TLS_INIT variable.

Setting this on an architecture makes Mini call
mono_arch_tls_init () on thread attach.

This is primarily useful for architectures that have not
had their LMF code ported to the new infrastructure due to
a general lack of maintenance or hardware to do it on.
Remove 32-bit s390 support from configure.in as well.
Revert "Fix the win64 build."

This reverts commit 2975c3c9b5f8e741702591824107b07e6510ae0a.

Revert this as it seems to break the windows build.
Move mono-mutex.c from io-layer to utils. Killing the io-layer, softly.
Remove support for for pthread implementations that lack recursive mutexes.

	* configure.in: Don't define USE_MONO_MUTEX. No sane posix system from this
	millennium lacks recursive mutexes. Given that, let's just fail mono on them
	and drop a bunch of dead code.
Cleanup the interface of mono_mutex_init.

	* mono-mutex.h: mono_mutex_init no longer takes a mutexattr,
	it's always non-recursive and returns zero on success.

	* mono-mutex.h: Add mono_mutex_init_recursive for those that need
	one. This makes the API much much nicer for win32 consumers. Caching
	the mutexattr on posix is really a waste of time. Mutexes are heavyweight
	objects such that their creating will never be on the fast path.
Remove the now unused mono_mutexattr family of functions.
Remove static initializers as they are not portable under windows.
Remove some dead defines from mono-mutex.h
Introduce a new kind of mutex, the suspension safe one.

	* mono-mutex.c: Add mono_mutex_init_suspend_safe so special targets
	like OSX that have broken implementations of suspend for pthread mutex
	will hang less.

	A suspension safe mutex means one that can handle this scenario:

	mutex M

	thread 1:
	1)lock M
	2)suspend thread 2
	3)unlock M
	4)lock M

	thread 2:
	5)lock M

	Say (1) happens before (5) and (5) happens before (2).
	This means that thread 2 was suspended by the kernel because
	it's waiting on mutext M.

	Thread 1 then proceed to suspend thread 2 and unlock/lock the
	mutex.

	If the kernel implements mutexes with FIFO wait lists, this means
	that thread 1 will be blocked waiting for thread 2 acquire the lock.
	Since thread 2 is suspended, we have a deadlock.

	A suspend safe mutex is an unfair lock but will schedule any runable
	thread that is waiting for a the lock.

	This problem was witnessed on OSX in mono/tests/thread-exit.cs.
Rework MulticastDelegate.Equals to use a loop instead of recursion.

This should aid in tracking down bugs such as #11871 (or possibly even
fixing them) - if the problem still exists the process will run into
an infinite loop, which is a lot easier to debug (at least on iOS, and
likely other platforms too) than a stackoverflow.
The build bots run on Snow Leopard that doesn't have pthread_spis.h. Let's revert this for now until the bots are switched to lion.
Update failing test