This restores behavior from before 5a7d75cd.

I've also tried saving a cancel cookie from `BeginCreateObject*` and using it to cancel the
operation in engine shutdown. However there are 2 problems:

  1. Callback might still get called after `CancelObjectCreation`. Microsoft's
     [own documentation](https://learn.microsoft.com/en-us/windows/win32/api/mfidl/nf-mfidl-imfsourceresolver-cancelobjectcreation)
     says as much:
       > Because these methods are asynchronous, however, they might be completed before the
       > operation can be canceled. Therefore, your callback might still be invoked after you
       > call this method.
  2. Our implementations of `BeginCreateObject*` are not cancellable. They call either
     `MFPutWorkItem` or `IMFByteStream_BeginRead`, neight of which provides cancellation.
     (and our `CancelObjectCreation` doesn't actually work. AsyncResult objects aren't added to
     `handler->results` list until they are completed, which means any attempts to cancel an
     yet-to-be-completed object creation will always fail with `MF_E_UNEXPECTED`)

Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=55588

This was reported as a out of bounds access (Coverity), which is possible
if the tid_NULL was ever passed in.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54113

Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=54342

This forces mesa LLVMPIPE driver to use a fixed number of threads, and
greatly reduces its memory usage from the $(nproc) default. On Gitlab
this is 32 threads, which often exhaust VM space in 32bit tests.

Found when wpfgfx_cor3.dll failed to relocate in Bentley CONNECTION Client.

Fixes: 56d9e1a8.

The error count wasn't be increased if tracing was disabled. eg CI.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55720

Fixes 65e38813, which is otherwise no-op
without this change.