C++: data flow through partial chi operands where type is known

[jbj]

This PR builds on top of #2667 and #2657, so I've initially opened it as a draft. The main change is in af8bbf4. As evidenced by the diffs, these changes together enable IR data flow through the most common case of definition by reference.

I've attempted to distinguish the unhelpful (for data flow) chi instructions from the helpful ones based on their result type. I thought originally that we'd need to thread some new predicates through the SSA construction, but the type-based approach seems to work. Maybe @rdmarsh2 or @dbartol can point out a case where it won't work.

[dbartol]

The result type of the Chi is actually a pretty good way to distinguish these, since it will always be the type of the virtual variable. A virtual variable with a known type should always represent a single known memory location, and a virtual variable with an unknown type would represent a group of disjoint memory locations. There are probably some cases where the known memory location is an array or struct, where a write to a single member will result in a Chi for the whole array/struct, that might confuse this a bit, but I expect that isn't common enough to worry about.

[rdmarsh2]

Won't stack-allocated structs normally be their own virtual variable? That makes this seem much more common to me.

[jbj]

Then a write to a field of a struct will cause data flow to the whole struct? That doesn't seem great. On the other hand, it's exactly what I'm trying to achieve for strcpy: a write to a portion of the output buffer should taint the whole buffer. So perhaps the code I'm introducing here belongs in TaintTrackingUtil rather than DataFlowUtil?

For data flow, perhaps we could require that the size of the partial operand equals the size of the chi result? I'm hoping that would support common cases of memcpy.

[jbj]

I've fixed merge conflicts and taken this PR out of draft state. There's still the open question of whether the flow should be data flow, taint flow, or maybe sometimes one and sometimes the other. I don't think that matters for the January deadline, though.

[jbj]

It turns out this PR doesn't go far enough to include everything we'll need after #2696. See https://github.slack.com/archives/CP0LHP150/p1580312043150500.

[jbj]

Solution pushed.

[jbj]

The last commit, 52d2beb, had no effect on the security qltests.

[rdmarsh2]

Looks good to me for now. We'll need to come back to where it fits in the core dataflow library