JS: QL-side type/name resolution for TypeScript and JSDoc

[asgerf]

Prepares for disabling TypeScript type extraction by recovering the relevant type information on the QL side.

Actually disabling type extraction will happen in a separate PR so it's easier to validate in isolation and rollback if needed.

The code is divided into three main components:

• Name resolution: resolve a type name or variable to its definition; looking through imports and (re-)exports.
• Type resolution: determine the type of an expression. Here we use a TypeExpr as a placeholder for an actual type which is good enough for our needs. Does not support generics.
• Underlying types: Determine the 'underlying types' of a type. The concept of "underlying types" is meant to provide library models a simple way of reasoning about named types without having to deal with unions, intersections, and subtyping relationship. For example (Request & { x: T }) | null has Request as an underlying type.

One of the complexities of TypeScript is the fact that there are three "declaration spaces" in which variables can exist: value, type, and namespace. For example, for a declaration like class C {}, the value C refers to the class itself (i.e. its constructor), whereas the type C describes an instance of the class (not the class itself). In practice, it seems that values and namespaces can be merged without problems so I decided to simplify things by doing that.

Effects on call graph

• Disabling type extraction on main would lose us 40k call edges on the default benchmark suite.
• The new QL-based implementation recovers 98% of those edges, only 746 edges were not recovered.
• On top of that, it discovers 30k new call edges that were missed in the original extractor-based implementation.
  • One of reasons for this is better support for JSDoc type annotations in .js files. The new solution has unified support for the two kinds of type annotations, which was not possible previously since we didn't want to run the TypeScript compiler on .js files.
  • Another reason is better tolerance for missing dependencies, as something like KnownClass | UnresolvedClass will always propagate information about KnownClass even if UnresolvedClass could not be resolved.

[Napalys]

Extraordinary... 👏

[erik-krogh]

I still haven't looked closely at the three big commits, but here are some small comments.