Use lock_guard<mutex> in itkPlatformMultiThreaderWindows, ParallelSparseFieldLevelSetImageFilter, and PDEDeformable Registration

[N-Dekker]

Following C++ Core Guidelines, April 13, 2023, Use RAII, never plain lock()/unlock()

Follow-up to pull request #4173 commit c4c3710 "STYLE: Use lock_guard<mutex> in PlatformMultiThreader classes"

[N-Dekker]

@dzenanz @blowekamp Thanks for your approval and your 👍 FYI, I found one more possible lock_guard<mutex> use case, in FFTWGlobalConfiguration::GetInstance():

ITK/Modules/Filtering/FFT/src/itkFFTWGlobalConfiguration.cxx

Lines 151 to 168 in 3eb8fd7

	m_PimplGlobals->m_CreationLock.lock();
	// Need to make sure that during gaining access
	// to the lock that some other thread did not
	// initialize the singleton.
	if (!m_PimplGlobals->m_Instance)
	{
	m_PimplGlobals->m_Instance = Self::New();
	if (!m_PimplGlobals->m_Instance)
	{
	std::ostringstream message;
	message << "itk::ERROR: "
	<< "FFTWGlobalConfiguration"
	<< " Valid FFTWGlobalConfiguration instance not created";
	itk::ExceptionObject e_(__FILE__, __LINE__, message.str().c_str(), ITK_LOCATION);
	throw e_; /* Explicit naming to work around Intel compiler bug. */
	}
	}
	m_PimplGlobals->m_CreationLock.unlock();

This one is somewhat more interesting than the ones addressed so far by this PR, because it throws an exception between the lock() and the unlock() call. I think that's a bug. (It might mean that the mutex would never be unlocked anymore! 🙀) Anyway, I can make that a separate PR.

[N-Dekker]

FYI, I found one more possible lock_guard<mutex> use case, in FFTWGlobalConfiguration::GetInstance()

...

Anyway, I can make that a separate PR.

Here it is, please have a look:

• BUG: Use lock_guard<mutex> in FFT configuration to deal with exception #4181

Both PRs can be processed independently.