Put the stdlib under the std namespace

[yannham]

Closes #1131.

This PR introduces a top-level value std in which lives the stdlib modules, to make them more discoverable, help completion, and avoid polluting the initial environment.

Design

There was a surprising number of small but non trivial dilemma to solve. The first is where this overarching std module should lie:

• It sounds appealing to simply generate a record programmatically from Nickel, such that we don't even have to change anything to the current stdlib code. However, this unfortunately doesn't play well with the LSP, which can't handle terms without positions in a file. This would break completion and type information without a serious rethink of how the LSP currently works.

• If we need a source (can be generated), then we can write a std.ncl file which simply imports the modules:

  {
    std = {
      array = import "array.ncl",
      string = import "string.ncl",
      ..
    }
  }
  

  The issue is that imports don't work for the stdlib, because it's included at compile-time in the binary.

• Then we can generate this file by doing compile-time concatenation/include_str/substitution. We still have a source code to provide to the LSP (albeit being generated), but we don't have to use imports. Now, the issue is that say a contract failure on std.array.at null null will point to code that exists nowhere (has been generated and concatenated from existing fragments), and the user has no way to find this code anywhere, and thus can't even know what function is failing, depending on the formatting. Hence, we want the std.ncl file to be accessible

• In the end, I went with squashing the modules together. Later on we might add special imports like import <std/array.ncl> which would allow to split the stdlib into separate files again, but this requires a bit of thinking. In the meantime, this decision put slightly more burden on us maintainers, but don't impact users (LSP is working, the file defining the stdlib is accessible as text).

Typechecking mutually recursive modules with polymorphic functions also proved challenging: thus, the enclosing std = { } is omitted (as opposed to the previous style) and inter-modules reference all goes through the std interface present in the initial typing environment, instead of being directly mutually recursive.

Reviewing

The important commits to review are:

• Introduce the std namespace (62e7b09)
• Update the LSP to work with the new std namespace (59d02a6)
• Update RELEASES.md (0a3c1e6)

The rest is mostly a painful search and replace to update all the existing Nickel code. We've tested the benchmarks as well, to make sure they are up to date. The benchmarks showed a noticeable regression on some examples. Showing the flamegraphs didn't really help, as although the proportion varied a bit, nothing really stood out. Running a bigger example for longer doesn't seem to make that much of a difference, so it might be that loading the stdlib or accessing it has a penalty which shows on micro-benchmarks.

TODO

• Fix panic in the LSP, because we're adding usages for std, but std doesn't get a Declaration or RecordField item. Should we just add an usage field to any node?
• Documentation: will be done in a subsequent PR
• Have a tentative fix for the LSP not completing on std

[vkleen]

Looks good! Just a few typos in comments 👍

[yannham]

Ah, completion for the stdlib is broken. I think I understood why, will probably fix in a coming PR, but I prefer to have a solution lined up before merging this one.

[yannham]

With the help of @ebresafegaga, we could restore the stdlib completion with a one-liner in 6186118.