impossible: don't mark returns as impossible if threads are involved

impossible: don't mark returns as impossible if threads are involved

Smatch doesn't understand threads at all.  So what would happen is that
you set foo->bar = 0; then wait for it to be set in another thread, and
then check the value again.  Smatch marks the non-zero paths as impossible
and CULLs them from the DB.  This means that the success path is marked
as impossible.

Of course, that means you miss some paths and some information.  But what
it also means is that when the callers check "if (ret) {" then Smatch
ignores the implications from that.  (Smatch ignores the implications from
known true/false conditions).  So that leads to confusing false positives.

Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>