IsMultiple in MallocWrapper: Check uniqueness of allocating(!) thread

[michael-schwarz]

To determine uniqueness of a malloced object, Goblint is supposed to perform the following logic:

• A: Check that is assigned a counter value (numbering mallocs within a thread) other than top
• B: Check that the allocating thread is unique

Unfortunately, the logic for (B) is broken: It checks whether the thread making a uniqueness query for the blob is unique, instead of the thread which allocated the memory in the first place.

The added testcase is a precision issue, but it also is a soundness problem.

If the querying thread happens to be unique but the allocating one is not, we give the wrong answer here. Because of various internals (always spawning the unique copy of a thread in a loop too), getting Goblint to actually surface the unsoundness was beyond me, though.

SV-COMP: After this blunder is removed, we might benefit in MemSafety and it may also be interesting to re-check if one should enable the malloc uniqueness for races (CC @karoliineh): With --set ana.malloc.unique_address_count 1, we now succeed on sv-comp/sv-benchmarks/c/pthread/twostage_3.i.

Closes #1719

[sim642]

I have deja vu that we've had a similar issue somewhere in the past, but couldn't easily find it.