Rust: Track closure types in data flow

[hvitved]

With this PR we track the types of closures in data flow, which can help improve precision of closure call resolution. We also implement getSourceContextParameterNodeType, which was introduced recently on #21592.

[Copilot]

Pull request overview

This PR updates Rust’s data flow implementation to incorporate closure “type” tracking (using closure expressions as unique type representatives) and adds support for the recently introduced getSourceContextParameterNodeType hook to improve precision in closure call resolution and source-call-context handling.

Changes:

• Introduces a DataFlowType representation for closures (plus unknown/source-context-parameter types) and wires it into the Rust data flow generator, including getSourceContextParameterNodeType.
• Refactors local must-flow steps (including explicit handling for parenthesized expressions) and integrates them into the generator’s must-flow logic.
• Extends the lambdas library test suite with apply/apply_wrap cases and updates the expected inline-flow output accordingly.

Show a summary per file

File	Description
rust/ql/lib/codeql/rust/dataflow/internal/DataFlowImpl.qll	Adds closure-aware data flow type support and the source-context-parameter type hook; refactors local must-flow stepping.
rust/ql/lib/codeql/rust/dataflow/internal/ModelsAsData.qll	Adjusts type-inference Type import usage to avoid ambiguity and qualify RefType.
rust/ql/test/library-tests/dataflow/lambdas/main.rs	Adds new apply/apply_wrap closure-flow test cases and expectations.
rust/ql/test/library-tests/dataflow/lambdas/inline-flow.expected	Updates expected inline flow graph output for the expanded test coverage.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 1

[Copilot]

The new $ SPURIOUS: inline expectations here don’t include a brief rationale. Adding a short -- ... explanation (like in other Rust tests) would make it clearer to future readers why these extra flows are currently accepted and what limitation they document.

Suggested change

	apply_wrap(|x| sink(x), a); // $ hasValueFlow=79 $ SPURIOUS: hasValueFlow=80
	let b = source(80);
	apply_wrap(|x| sink(x), b); // $ hasValueFlow=80 $ SPURIOUS: hasValueFlow=79
	apply_wrap(|x| sink(x), a); // $ hasValueFlow=79 $ SPURIOUS: hasValueFlow=80 -- analysis currently conflates flows across wrapped calls
	let b = source(80);
	apply_wrap(|x| sink(x), b); // $ hasValueFlow=80 $ SPURIOUS: hasValueFlow=79 -- analysis currently conflates flows across wrapped calls