Clarify support for exclusive_trylock_function annotation on constructors

[apasel422]

The mutex demo in the Thread Safety Analysis documentation demonstrates a number of MutexLocker constructors that assume various properties about the given mutex, but it notably omits a constructor that performs TryLock, instead providing that as a method on MutexLocker itself.

In attempting to address a bug related to a similar scoped lockable that tries to lock a given mutex we considered the possibility of annotating the constructor with exclusive_trylock_function(true) and adding an implicit operator bool() that returns whether locking succeeded.

I'm not sure whether the analyzer should support something like this, but is it ever appropriate today to mark a constructor with exclusive_trylock_function, given that constructors don't return anything? If not, could we make it an error to help prevent misuse, similar to the way it is prohibited on anything other than a function?

[pkasting]

What we ultimately landed here has its own downsides: it suggests that the "is the lock acquired?" oracle function is EXCLUSIVE_TRYLOCK_FUNCTION, which is misleading (but understandable), but worse, the destructor is marked as UNLOCK_FUNCTION, which is strictly false if the lock was not acquired, and in theory could cause bogus warnings (though the comments on ~MutexLocker() in the example suggest it won't).

Ultimately, IMO, the right solution is something like a new SCOPED_TRYLOCKABLE annotation to go with SCOPED_LOCKABLE, which would take an argument that is an expression which should evaluate to true iff the lock is acquired.