PTHREAD_MUTEX_DEFAULT handling is unsound

[sim642]

This is follow-up to #1410.

The specification for pthread_mutexattr_settype says:

PTHREAD_MUTEX_DEFAULT [...] An implementation is allowed to map this mutex to one of the other mutex types.

This means that all default-initialized pthread mutexes may actually be recursive and our analyses should behave as such.
In particular, the added tests reveal unsoundness in may-locksets where unlocking shouldn't remove a recursive mutex from the lockset because it may remain locked.

TODO

• Fix.
• Assume default is non-recursive.
• Document assumption in user docs.
• Make Goblint behavior consistent for three ways of creating default mutexes.

[michael-schwarz]

The question is what behaviour we want here. I think our default behavior should align with what the implementations do, and this is definitely not recursive. But maybe we should add an option to get this behavior.

[sim642]

Apparently 71-doublelocking/19-default-init fails on OSX because it doesn't seem to know that the mutex is non-recursive still. I'll have to look into it.