This PR implements two dataflow improvements. The combination of the two effects means we won't have new FPs on the cpp/invalid-pointer-deref after the frontend upgrade that @jketema is working on.

• The first commit improves out detection of which writes are considered "certain" (i.e., which completely overwrites an allocation) by using value numbering. Previously, we'd detect that that x = 0 in:

  int x = source();
  x = 0;
  sink(x);

  overwrites an entire allocation because it writes directly to a VariableAddressInstruction. Thus we wouldn't report flow from source to sink.
  However, we didn't detect that in the case of *p = 0 in:

  int x = source();
  int* p = &x;
  *p = 0;
  sink(*p);

  since *p = 0 wrote to the result of a LoadInstruction (and not a VariableAddressInstruction). However, value numbering can easily see that *p writes to an address that is equal to a VariableAddressInstruction.

• The second commit is a bit more complex. It addresses the following problem:
  Consider the following snippet:

  *--(*x) = 0;

  after the frontend upgrade this translates into the following IR (where I've stripped away the irrelevant parts):

  r1(char)           = Constant[0]              :
  r2(glval<char **>) = VariableAddress[x]       :
  r3(char **)        = Load[x]                  : &:r2
  r4(glval<char *>)  = CopyValue                : r3
  r5(char *)         = Load[?]                  : &:r4
  r6(int)            = Constant[1]              :
  r7(char *)         = PointerSub[1]            : r5, r6
  m10(char *)        = Store[?]                 : &:r4, r7
  r9(char *)         = Load[?]                  : &:r4
  r10(glval<char>)   = CopyValue                : r9
  m11(char)          = Store[?]                 : &:r10, r1

  and assume we have flow into *r4 (i.e., the CopyValue instruction behind one level of indirection. This can be interpreted as "the value of x is tainted"). Dataflow then transfers flow from *r4 to *&:r4 (i.e., the address operand of r9). However, notice that there's a Store to the exact same address just before the load of the address. So, in fact, we shouldn't have flow from *r4 to *&:r4 because there's a write to *&:r4 in between those.

  This last commit addresses this problem by removing those dataflow edges when there's a StoreInstruction in between the defining instruction and the operand.

  The predicate introduced isn't exactly pretty, but it seems to perform okay on the databases I've tried so far. Ideally, I'd like to replace this with use-use flow through the IRs instructions and operands (instead of the current def-use strategy that's native to what the IR provides), but that's a slightly more involved change than what I'd like to do here.