[DRAFT] [starvation] model std::scoped_lock with several mutexes and std::adopt_lock

[VladimirMakaev]

Stack: #2182 → #2172 (review only the top commit; lands after #2182)

Infer parsed std::scoped_lock like the other guards, as (mutex[, tag]), and a guard could own
only one lock. So scoped_lock l(m1, m2) acquired nothing, three or more mutexes were not parsed,
and the std::adopt_lock forms never released their mutexes. Starvation missed deadlocks and
RacerD missed races:

struct C {
  std::mutex m1, m2, m3;
  void thread1() {
    std::scoped_lock l(m1, m2);
    std::lock_guard<std::mutex> g(m3);
  }
  void thread2() { // Infer missed: deadlock with thread1
    std::lock_guard<std::mutex> g(m3);
    std::scoped_lock l(m1, m2);
  }
};

GuardConstruct now carries a list of locks, and std::scoped_lock gets its own parser, which
recognises the std::adopt_lock_t tag by type; destroying a guard releases all its locks. A
multi-mutex acquisition (std::lock, std::scoped_lock) that relocks a held non-recursive mutex
is now a self deadlock even when another of its mutexes is recursive.

Test plan

New cpp/starvation/scoped_lock.cpp, with an FN_ test for std::try_lock followed by
std::adopt_lock, and new cases in cpp/racerd/scoped_lock.cpp. cpp/starvation now compiles
with -std=c++17; its only other effect is that guaranteed copy elision makes the copy-initialised
guard in custom_guards.cpp recognised, so that test loses its FN_ prefix. The codetoanalyze
tests pass.