Ark: Analysis: Use static analysis when possible in the LSP

[lionel-]

Now that we generate fake source files for namespaces missing a source (currently with #2285, but also #2286 and #2282 in the future) we are in a better place to analyse and index package namespaces statically instead of inspecting the runtime state.

Static analysis is preferable (a) for safety reasons as we currently evaluate too much code at interrupt time, (b) for more accurate scope information sensitive to the context, e.g. to improve jump-to-definition or find-usages behaviour inside functions, and (c) for performance because we can continually do work instead of waiting for our turn on the R event loop.

As a data-analysis oriented IDE we're facing a particular challenge: The user develops their code interactively and we'll still want to track the global objects created interactively using runtime inspection. But we can index those objects at idle time rather than inspecting these concurrently with the user's running code like we currently do. We'll also need to strike the right balance for our diagnostic tools powered by static-analysis so that users can develop pieces of code without being annoyed by distracting lints.

First tasks for moving towards static information:

• Index the functions of namespaces to power completions, jump-to-definition and find-usages.

  • The namespace index should include scoping information: Imports and Exports as defined in NAMESPACE.
  • The function index should include their source spans and argument signatures.

• Currently in virtual sources created with the reparsing approach we ignore functions that can't be reparsed and other kinds of objects. In the future we'll want to still include those in the source in some form so that they can be statically analysed, e.g. foo <- function(my, signature) _source_unavailable.

  Side note: Eventually we'll also gain some basic support for type inference or type annotations, as well as scope annotations in NSE functions. Since we control the fake sources of the base packages, this is the place where we'll attach virtual declare() annotations for the subset of base functions with known semantics. This will allow us to experiment and develop with annotations (scoping info of NSE functions, type info of arguments and return values) for base packages.