While working on MaD support for barriers/barrier guards for C/C++ I discovered a bug related to indirect barrier guards. This PR fixes that bug at the cost of:

• Exposing a predicate that was private in the shared Guards library, and
• Losing a small bit of smartness in barrier guards related to stuff like:

  if(x == y && clean(x)) {
   sink(y); // okay because `clean` is a barrier and `x == y`
  }

The problem is that (as @aschackmull also discovered when we were porting C++ to the shared SSA library's dataflow integration layer) we cannot relate an SsaDefinition to an Instruction without an indirection index. So on something like:

void foo(int* p) {
 if (validate_indirection(p)) {
 sink(*p);
 }
}

When guardChecksInstr says that p is a barrier guard with indirection 1 guardChecksDef finds the associated Ssa definition for p (and not its indirection, *p, since guardReadsSsaVar doesn't have access to the indirection index) and places a barrier on &p, p, and *p instead of just *p like it was intended.

I can imagine better fixes for this. In particular:

• Thread an additional language-supplied data column through the guards library and make it available for getARead.
• C/C++ instantiates the shared Guards library with AstNode = (Instruction, int) instead of AstNode = Instruction like we do currently. This should be totally doable (albeit with another breaking change to the barrier guards library for C/C++ 😭)

@aschackmull do you have any thoughts on this?

In the first commit I switch dataflow to use Type instead of DataFlowType. This may look scary, but DataFlowType is just Type with an empty toString (see here). This was necessary to create the testcase I wanted.