Fix var_eq analysis not invalidating escaped variable

[sim642]

This is the source of unsoundness for SV-COMP goblint-regression/28-race_reach_45-escape_racing.yml (issue #141), which is actually from our regression suite. There it doesn't fail because it's run without var_eq.

var_eq keeps the equality i == 0 after i escapes through the 4th argument of pthread_create. Changing LibraryFunctions to invalidate that argument also fixes this test, but breaks 05/17. Because of this I'm not sure if this is the right fix or maybe there's something better to do.

I suspect not because our invalidation and var_eq are quite ignorant about passing pointers. In one case &i is passed, in the other only p. The thing is that the argument (which is a pointer) itself wouldn't be changed by such pthread_create but only whatever the argument points to.

Another oddity is that base also doesn't invalidate i in that example. But only later when it is read (for the assertion), the global invariant is used instead because according to escape it has escaped.

[sim642]

Hard-coding the pthread_create argument invalidation only to var_eq seems to fix the issue without introducing a regression.

I guess it wasn't set to invalidate in LibraryFunctions to avoid generating a spurious write access directly on pthread_create itself.