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

When calling `lock()` and `unlock()` explicitly, throwing an exception between
between those two calls would leave the mutex locked, which appears undesirable.
Used `std::lock_guard` to solve this problem.

Following C++ Core Guidelines, April 13, 2023, "Use RAII, never plain `lock()`/`unlock()`"
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp20-use-raii-never-plain-lockunlock

Also replaced manual creation of an exception with an `itkGenericExceptionMacro`
call.

Modules/Filtering/FFT/src/itkFFTWGlobalConfiguration.cxx

@@ -148,7 +148,7 @@ FFTWGlobalConfiguration::GetInstance()
   itkInitGlobalsMacro(PimplGlobals);
   if (!m_PimplGlobals->m_Instance)
   {
-    m_PimplGlobals->m_CreationLock.lock();
+    const std::lock_guard<std::mutex> lockGuard(m_PimplGlobals->m_CreationLock);
     // Need to make sure that during gaining access
     // to the lock that some other thread did not
     // initialize the singleton.
@@ -157,15 +157,9 @@ FFTWGlobalConfiguration::GetInstance()
       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.  */
+        itkGenericExceptionMacro("Valid FFTWGlobalConfiguration instance not created");
       }
     }
-    m_PimplGlobals->m_CreationLock.unlock();
   }
   return m_PimplGlobals->m_Instance;
 }