[clang] Thread Safety Analysis: Warn when using negative reentrant capability (PR #141599)

[Marco Elver via cfe-commits]

melver wrote:

> On a related note, do we emit `-Wthread-safety-negative` for reentrant locks? I don't remember that we carved out an exception for that, and we probably should.

We do - and it's deliberate on my part as I've been trying to indicate that there might be valid use cases for that. While conceptually contradictory, there might be cases where developers want to ensure a reentrant mutex is NOT held before entering a function.

I'll give you an example:
```
class Example {
  ReentrantMutex mu;
  ... 
    // Performs heavy I/O (write to file), blocking many seconds...
    void expensiveIO(..) REQUIRES(!mu);
};
```
While technically ok to enter expensiveIO() with the mutex held, it would prohibit forward-progress in other threads. This is a liveness bug, and negative capabilities can help catch such cases, too. While `EXCLUDES(..)` can also help, I do like negative capabilities for their strictness. Whether or not the developer is able to use a non-reentrant Mutex here is a different question - but e.g. more uncommon synchronization mechanisms like interrupt locking, preemption locking, or RCU fundamentally are reentrant.

I would like to account for OS kernel code needs, too (RCU also exists for user space).

https://github.com/llvm/llvm-project/pull/141599