C++: Generate int-to-bool conversions in C code

[MathiasVP]

In C++ code we have int-to-bool conversions on myInt in examples like:

void test(int myInt) {
  if(myInt) {
   // ...
  }
}

That is, it's not myInt that is branched on, but rather the result of myInt != 0. In the IR, this manifests as the IR looking like:

r1_5(glval<int>) = VariableAddress[myInt]     :
m1_6(int)        = InitializeParameter[myInt] : &:r1_5
r2_1(glval<int>) = VariableAddress[myInt]     :
r2_2(int)        = Load[myInt]                : &:r2_1, m1_6
r2_3(int)        = Constant[0]                :
r2_4(bool)       = CompareNE                  : r2_2, r2_3
v2_5(void)       = ConditionalBranch          : r2_4

(notice the BranchNE instruction).

This information is important in guard conditions since branching on myInt doesn't tell us that myInt == 1, but rather that (myInt != 0) == 1.

This is all well and good in C++. However, in C, there are no int-to-bool conversions. So when compiling the same code with a C compiler the IR looks like:

r1_5(glval<int>) = VariableAddress[myInt]     :
m1_6(int)        = InitializeParameter[myInt] : &:r1_5
r2_1(glval<int>) = VariableAddress[myInt]     :
r2_2(int)        = Load[myInt]                : &:r2_1, m1_6
v2_5(void)       = ConditionalBranch          : r2_2

(notice that we're now branching on the value of myInt)

Historically, we've worked around this problem in IRGuards specifically (see #16364 and #16533), but upon facing a related problem somewhere else I now feel like we should simply make the IR equivalent in C and C++.

So this PR inserts IR equivalent to what would have been generated for an int-to-bool conversion if it had been present in the database in the places I'm aware of this being a problem. It then removes the workarounds in the guards library that were added to handle these.

Commit-by-commit review recommended (especially for the IR construction related commits).

DCA reveals a few new results and a few lost results:

• The lost cpp/overrun-write and cpp/path-injection results are because both queries use any guard as a barrier, and we now recognize more barriers.
• The cpp/redundant-null-check-simple results are new TPs 🎉

I've verified that the new TPs are real TPs caused by us recognizing more guards in C code (🎉), and I've verified that the removed results are