Dataflow: Refactor stage 6 to use shared stage code.

[aschackmull]

This extends the StagePathGraph and corresponding nodes to fully match the existing PathGraph and PathNode. With that in place, the existing stage 6 code is replaced by an instantiation of the Stage module to reduce code duplication.

Things to note:

• Proper checking of clearsContent on store targets used to be postponed to stage 6, so this needed to be added to the StagePathGraph as well. Given that we now base the flow computation on node-reachability instead of edge-reachability, this means that we'll need to do a final forward reachability check to prune PathNode in order to avoid unreachable edges, since an edge using reachable nodes might be reverse-reachable from a sink without being forward-reachable.
• Stateful in/out-barriers used to only be checked in the pathStep predicate, so in order to continue to support this, the check has been pushed into the general stage computation.
• Provenance for flow-through edges no longer need to rely on additional information stored in PathNodes (the summaryLabel), but can instead be computed in a separate predicate. This gets rid of a lot of superfluous PathNodes (as can be seen in several qltests).
• There's a small change to how we track a summary context due to differences between the prior implementation in pathStep and the current implementation in the stage modules. The latter includes the call site to determine whether flow-through is possible and hence whether to construct a summary context. For certain cases where a call target can have both flow-through from one call-site and flow-but-not-through from another call-site, this can result in a few additional PathNodes. This can be seen in the changes to the C++ qltest expected output.
• We get a few additional subpaths when detecting subpath-wrappers in hidden code in the case when a flow-through path relies on two (or more) chained nested flow-through steps. This shows in a couple of qltests for some of the more involved library models, e.g. the C# Linq Aggregate method, which chains its data through two callbacks.

Commit-by-commit review is strongly encouraged. I made effort to split the changes into separately reviewable commits.

Fixes https://github.com/github/codeql-team/issues/3234

[aschackmull]

This change actually gets us a tiny precision improvement: Previously, the reachability in pathStep relied on consCand (aka push/pop) relation that was materialised up front, which meant that it used the output of Stage 5. But now, stage 6 is mutually recursive with its own cons-candidate relation. When access paths are fully precise (which they often are in stage 6) then this doesn't make any difference, but when stage 6 access paths are approximated, then this can make a small difference. This accounts for the removal of a few FPs highlighted in C# dca.

[geoffw0]

CPP changes and DCA LGTM (as does Swift DCA). 👍

[hvitved]

Thanks a lot for making this refactoring, that makes the code much more maintainable.

[hvitved]

Alternatively, you could define private class TPathNode = TPathNodeMid or TPathNodeSink and then add TPathNode to the extent of PathNode.

[aschackmull]

That wouldn't remove the need for a charpred, so I don't think it would gain much - TPathNode would still be larger than PathNode.