FlowSummaryImpl: Embed AST nodes in source/sink summary nodes for better flow paths

[hvitved]

This PR addresses the issues identified by @MathiasVP on #22113.

Note that the issue (and fix) only applies to Rust, which is the only language that currently supports source/sink definitions with non-empty access paths.

The underlying issue was that we were unable to map source/sink summary nodes to the locations represented by the output/input models-as-data specs, so for example a source with an Argument[0] spec would be unable to be mapped to the corresponding argument, and we instead resorted to using the location of the call as the source location. The second issue identified by @MathiasVP, defining a source that is supposed to be a parameter, was not even supported in Rust.

The fix to both issues is to embed language-specific AST nodes into the source/sink summary nodes, and then use the locations of those as the locations of the source/sink nodes. This PR also shows how to add support for parameter sources, as well as more complex sinks like Argument[0].ReturnValue.Field[A].Field[B] (a value stored inside B stored inside A, which is returned from a callback at position 0).

For source/sink specs with complex access paths like the one above, we include a data flow node for each of the access path tokens, which means we can get much more helpful flow paths:

let a = |a| {
    let s = source(1);
//          ^^^^^^^^^ source (both before and after)
    return s;
//         ^ sink before, intermediate node after
};

// a sink with access path `Argument[0].ReturnValue`
complex_sink(a);
//           ^ sink after

Commit-by-commit review is strongly encouraged, and the second commit should be reviewed ignoring whitespaces.

The impact for Rust is that some alert locations have changed (to more precise locations, and in alignment with other languages), and I have added a change note for this.

[hvitved]

Ping @geoffw0 for the Rust alert location changes (improvements).

[geoffw0]

I'm happy with the changes to Rust tests, including locations. They're pretty wide-spread, I can see why you went with a majorAnalysis change note. I'm still checking some details of the DCA run...

[geoffw0]

Sorry for the delay, I am happy with all this now (at least the bits I reviewed - Rust test changes and DCA run).

[MathiasVP]

Thanks a lot for doing this, Tom! I think the code looks good to my relatively unfamiliar eye. I've pattern matched myself to a couple of inconsistencies that I think are bugs, though

[MathiasVP]

Should this be isSinkInputState?

[hvitved]

Yes, it should.

[MathiasVP]

I may be wrong, but this rewrite looks odd to me.
Prior to this we had:

pred = sinkElementInputState(sink, stack.tail()) and
succ = sinkElementInputState(sink, stack)

and now we have (after some substitutions):

pred = sinkElementInputState(sink, e, stack) and
succ = sinkElementInputState(sink, e, stack.tail())

which doesn't seem equivalent to me. Did you perhaps want stack0 = stack.tail() (which, I think, would make the two equivalent)

[hvitved]

It's because in the old version, we processed the state stack bottom-up, but now we process it bottom-down, so this rewrite is deliberate. But thanks for checking.

[MathiasVP]

I think this disjunct should be moved out of the enclosing exists as otherwise we also require:

StepsInput::getSummaryNode(pred) = predSummary

[hvitved]

You are right that this was not optimal (but not incorrect); I will fix.