BUG: Match behavior of SimpleFastMutexLock on different platforms (#ITK-3248)

The WinAPI and the pthread implementation behaved differently regaring recursive locking.

The WinAPI implementation used "InitializeCriticalSection" and "EnterCriticalSection" which let the thread holding the mutex call EnterCriticalSection again without blocking:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682608%28v=vs.85%29.aspx

In contrast the pthread implementation used pthread_mutex_init and pthread_mutex_lock whose behavior concerning this matter was dependent on the initialization parameters of the mutex. The default (which was used in ITK) doesn't allow recursive locking:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html

I suggest to adapt the pthread implementation because it seems to me that the current behavior of the WinAPI implementation is the one expected by most users.

Change-Id: Ic75fab3eedd1b457c531668b7786501a139426ba
Merge topic '3248-platform-dependent-mutex'

f8d8c7b9 BUG: Match behavior of SimpleFastMutexLock on different platforms (#ITK-3248)