tdf#116147 guard triggerRequestThreadAware

It didn't help putting a SolarMutexGuard into
VCLXButton::ProcessWindowEvent, which was my first suspect in my
own backtrace, as VCLXWindowImpl::OnProcessCallbacks releases it
to process the callbacks.

Since the gtk backend also guards all calls into the file picker
code, I think it's save to do the same for the Windows picker.

I have no idea where it is actually released again...

Change-Id: I3ab3b47904dc3d0033739a82f7afd91e6e80403d
Reviewed-on: https://gerrit.libreoffice.org/50783Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

fpicker/source/win32/filepicker/asyncrequests.cxx

@@ -138,6 +138,7 @@ void AsyncRequests::triggerRequestThreadAware(const RequestRef& rRequest,
 {
     oslThreadIdentifier nOurThreadId    = getIdentifier();
     oslThreadIdentifier nCallerThreadId = ::osl::Thread::getCurrentIdentifier();
+    SolarMutexGuard aGuard;
     if (nOurThreadId == nCallerThreadId)
         triggerRequestDirectly(rRequest);
     else if (nWait == BLOCKED)