And avoiding race condition while doing so.

Usually the threadpool holds a reference to the work_item, which is released when the work_item's
callback is invoked. However queue_cancel_item closes the threadpool object without releasing it,
leading to a leak. The fix is not as simple as adding a IUnknown_Release, because the work_item's
callback can still be called after CloseThreadpoolTimer/Wait has returned. In fact its callback
might currently be running. In which case we would double release the reference.

We have to stop any further callbacks to be queued, wait for any currently running callbacks to
finish, then finally we can close the threadpool object. After that, if the callback wasn't called,
we can safely release the work_item reference.