JS: Handle calls to bound functions

[asgerf]

Extends our call graph to deal with calls to bound functions, that is, functions created by a partial invocation such as fn.bind(x, y). For example:

function foo(x, y) {}
let fn = foo.bind(this, 0);
fn('hey'); // 'hey' flows to parameter 'y'

It is not enough to simply add these to getACallee and FlowSteps::calls() since that wouldn't take into account that the argument-to-parameter mapping is not 1:1.

So "bound calls" are handled as a first-class concept in the data flow libraries. We could generalize ordinary calls to be seen as "bound calls with zero bound arguments and unbound receiver", but since the overwhelming majority of calls are plain calls, it seemed wasteful.

We already type-track the result of partial invocations, for use in library models that require aggressive tracking into callbacks (getABoundCallbackParameter). We now use the same type-tracking to create the call graph for bound calls.

To avoid spurious flow, we distinguish cases where a bound function was tracked into a call from those that weren't. If it wasn't tracked into a call, we add a call edge that's assumed to hold in any context. If it was tracked into a call, we use our existing handling of callbacks to track the flow.

Evaluation looks fine.

[esbena]

This seems fine, but before I check the details, I would like to confirm that the following is intentional:

We do not use type tracking for callees in the callgraph, we only use ordinary dataflow and then type tracking for an eventual class/instance. But this change will permit type tracking for the bound function callees - right?
Semantically, it is fine, but it is inconsistent architecturally IMO. As a consequence we will get better results for f = bind((x) => sink(x)) than for f = (x) => sink(x).

[asgerf]

but it is inconsistent architecturally IMO

Indeed. I've been meaning to track functions as well, but this will require a separate evaluation.

[esbena]

Still LGTM, but I found a few nits.
Do we want a generic change note for "improved callgraph"?

[esbena]

Implementation LGTM then.

Do we want a generic change note for "improved callgraph"?

[asgerf]

Rebased to fix a conflict and added change note.

I'd like to run a another short evaluation since the other PR involving partial invocations has landed.

[asgerf]

Evaluation still looks good.

@esbena I rephrased the change note a bit, could you take a quick look?