This provides variable capture in standard situations:
- nested functions
- lambdas
There are some deficiencies:
- we do not yet handle objects capturing variables.
- we do not handle variables captured via the `nonlocal` keyword.
  This should be solved at the AST level, though, and then it
  should "just work".

There are still inconsistencies in the case where
a `SynthesizedCaptureNode` has a comprehensions
as its enclosing callable. In this case,
`TFunction(cn.getEnclosingCallable())` is not
defined and so getEnclosingCallable does not exist
for the `CaptureNode`.

TODO:
The member predicate `LibraryLambdaMethod::getACall` is
currently too permissive.
Ideally, we would have `libraryCallHasLambdaArg`
as in Ruby. But even a more precise
`libraryCall` predicate might be fine.

On the small test project, this reduces the number
of instances from 285 to 22.

as in Ruby

These are the labmda self references. This is similar to
how `BlockParameterArgumentNode` is excluded for Ruby.

It is important that we restrict `call` in this logic.
Otherwise, we get a cartesian product and the consistency
check runs for a very long time...

This depends on the extractor fix

this must have been lost in my
clean-up rebase.

Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>

also improve comment

…atch.qll

Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>

…ate.qll

Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>

into its own file.

…aptured-variables-basic

introduced by bad merge

for `CapturingClosureArgumentNode`.

Unless we define it for every single `CallNode`, we need a more
sophisticated mutual recursion with the call graph construction.
There is built-in support for that, but we are currently not using it.

Otherwise we get loads of nodes with missing locations
from the brnach nodes that are not matched.

next to `SynthCaptureNode`

- on debug predicates
- on JS implementation

Avoid the term "closure" as it is somewhat academic.

This will be added in a follow-up PR instead.

I chose `category: majorAnalysis`, the description is
"An API has changed in a way that may affect the results produced
by a query that consumes the API."
The API in question here is `flowPath` which is used by all our
data flow queries.

Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>

otherwise we confuse captured variables
in the single scope entry cfg node. Now
we have one for each defined variable.

TODO: Add test to demonstrate gain.

also, it is slightly incorrect...