[VladimirMakaev]

Stack: #2167 → #2205 (review only the top commit; lands after #2167)

Starvation matched locks across threads only with equal root types and accesses, and searched for
the other thread only in the root class of a lock, so Client's this->owner->first never matched
Owner's this->first:

#include <mutex>

struct Owner {
  std::mutex first, second;
  void lock_first_then_second() { std::lock_guard<std::mutex> l1(first), l2(second); }
};
struct Client {
  Owner* owner;
  void lock_second_then_first() {
    std::lock_guard<std::mutex> l1(owner->second), l2(owner->first); // Infer missed: DEADLOCK
  }
};

An object reached through fields may now be the root of another thread's lock, unless an earlier
object on the path has its class (as in a list), and every class on the lock paths is searched,
also in Java and for C structs in whole-program mode. Deduplication keeps deadlocks that only one
side finds. A thread in wait() blocks the UI thread only if another lock it holds may be the UI
thread's.

Limitations: gate locks reached through members count as common, as for parameters; starvation is
searched only from the UI thread, which does not match its this->m with another class's
this->owner->m.

Test plan

New tests in member_locks.cpp, member_locks.c, MemberLocks.java and ObjWait.java, and new
cpp/starvation-dedup and c/starvation-dedup directories. Main reports only the TreeNode
deadlocks, FN_gate_then_ba_bad and ObjWaitHoldsOtherParam, and falsely ObjWaitOnOnlyLock.
Parameters.oneWaySyncOnParamBad now reports the other side of its deadlock. All codetoanalyze
tests pass.

[VladimirMakaev]

Will reopen once current PR queue is cleared