Data flow: Synthesize parameter return nodes

[hvitved]

This PR adds synthetic return nodes for flow that returns from methods via a parameter. For example, in

class C
{
    public string Field;
}

public void TaintField(C c) // (1)
{
    c.Field = "taint"; // (2)
}

void M(C c)
{
    c.TaintField(); // (3)
    Sink(c.Field);
}

we would previously have a direct flow step from [post] c at (2) to [post] c at (3), whereas now we first have a step from [post] c at (2) to c [Return] at (1), and then from c [Return] at (1) to [post] c at (3).

The motivation for adding the extra node is two-fold: Firstly, it may help with generating fewer subpaths, and secondly it will be easier to follow flow path explanations (especially when the parameter write happens in a large method).

[aschackmull]

Suggested change

	* Gets the MaD string represention of return through parameter at position
	* Gets the MaD string representation of return through parameter at position

[aschackmull]

Suggested change

	* Gets the MaD string represention of return through parameter at position
	* Gets the MaD string representation of return through parameter at position

[aschackmull]

I don't think we usually comment on the latter aspect.

Suggested change

* The data flow library now adds intermediate nodes when data flows out of a function via a parameter, in order to make path explanations easier to follow. The intermediate nodes have the same location as the underlying parameter, but must be accessed via `PathNode.asParameterReturnNode` instead of `PathNode.asNode`. `@kind path-problem` queries may have their expected test-output changed as a consequence.

* The data flow library now adds intermediate nodes when data flows out of a function via a parameter, in order to make path explanations easier to follow. The intermediate nodes have the same location as the underlying parameter, but must be accessed via `PathNode.asParameterReturnNode` instead of `PathNode.asNode`.

[aschackmull]

LGTM