C++: share TOperand across IR stages

[rdmarsh2]

This follows on to #3612 by merging TOperand across IR stages. We create a single TOperand IPA type, with individual branches of this type for operands created directly from the AST (TRegisterOperand and TNonSsaMemoryOperand), phi nodes created by unaliased SSA (TUnaliasedPhiOperand), and phi and chi nodes created by aliased SSA (TAliasedPhiOperand and TAliasedChiOperand), as well as an empty placeholder branch to use in parameterized modules (TNoOperand).

Each stage's Operand.qll creates a private union type, TStageOperand, and the existing Operand class now extends it.

I've opened this PR in draft mode to run the differences job for performance testing - in my testing it looked like it reduced tuples in the IR stage by about 11%, but wall-clock time was too noisy to draw any conclusions. There weren't any tuple-count effects on later stages of the query I was running.

[rdmarsh2]

I've started a CPP-Differences job: internal link

[rdmarsh2]

The tuple count parser I was using didn't handle query stages properly - there's visible effects there when I look at the logs directly, and the ones I've seen so far involve joins that now use Operand predicates but previously used predicates from a specific subtype of Operand

[MathiasVP]

I think this looks good to me! I'll let more eyes look at this before approving, though. Do we want to run a fresh CPP-difference?

[dbartol]

Are there fresh CPP-Differences results? I'm fine with the code changes as long as the diffs aren't surprising.

[rdmarsh2]

New CPP-Differences: internal link

[rdmarsh2]

It looks like the disappearing operands are mostly related to fallthrough returns for functions with an int return type. I'm not sure what semantics we actually want for those. I'll think about it, but it might end up being a question for @dbartol when he's back.

[rdmarsh2]

I've started caching the charpred of the per-stage Operand class, and started a new CPP-Differences job: internal link

[rdmarsh2]

I don't see anything to explain the kamailio and wireshark slowdowns in local evaluation or tuple counts, but they're far too big to dismiss as cloud variance without a proper rerun. I've started a rebuild with just those two projects.

[rdmarsh2]

No result changes from those runs, and the rerun has sub-1% changes in performance, so I think I'm OK with the performance aspect now. I've just pushed an autoformat fix.

[jbj]

There's another autoformat error: ql/cpp/ql/src/semmle/code/cpp/ir/implementation/internal/TOperand.qll would change by autoformatting

[dbartol]

LGTM modulo autoformat test failures. Feel free to merge once those are fixed.

[dbartol]

I'm curious about whether caching at every level of the Operand hierarchy was necessary, or whether caching only the leaf classes would be sufficient. Performance numbers look great as-is, so no reason to change anything now. Just food for thought.