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.