[DRAFT] [starvation] model android::Mutex and recognise custom scoped guards

[VladimirMakaev]

Starvation only knows a fixed list of scoped guards. With any other, eg android::Mutex::Autolock,
the lock taken in the guard's constructor was read as a lock of the caller, so all guards
collapsed into one lock: inversions were missed and self deadlocks reported.

#include <mutex>

struct Guard {
  explicit Guard(std::mutex& m) : m_(m) { m_.lock(); }
  ~Guard() { m_.unlock(); }
  std::mutex& m_;
};

class C {
  std::mutex mu1_, mu2_;
 public:
  void thread1() { Guard a(mu1_); Guard b(mu2_); } // false positive: self deadlock
  void thread2() { Guard b(mu2_); Guard a(mu1_); } // same; Infer missed: deadlock with thread1
};

Callee locks are now substituted for every argument and at every call depth, and dropped when the
caller cannot express them. A local object whose constructor (or by-value return, if its
destructor releases a lock) leaves one lock held becomes a guard of that lock. android::Mutex and
Autolock are modelled, tryLock and timedLock as trylocks returning zero on success; RacerD now
also reports races in classes using them.

Trade-off: callee locks and unlocks the caller cannot express are dropped, missing deadlocks
through objects returned by calls (eg Java singletons) and keeping locks released through a local
guard struct.

Test plan

New tests in c/starvation/lock_wrappers.c, cpp/starvation (android_mutex.cpp, custom_guards.cpp,
substitution.cpp), cpp/racerd/android_mutex.cpp and java/starvation/Parameters.java, with FP_/FN_
tests for the limitations. The codetoanalyze tests pass.