Transition all relevant testcases to it. In the process, port
docstrings/comments from test.py files to expected_concrete_syntax.lkt
(now test.lkt) sources and fix stylechecks issues there.
(cherry picked from commit e1c4fe5804)
This makes the convention consistent with the DSL, and avoids
workarounds for conflicts with Lkt keywords: in Libadalang, the Null
token can stay Null, instead of null_tok (no API breakage needed).
This change enhances the unparsing engine so that template instantiation
keeps track of tokens from the source code to reformat as the unparsed
token are produced.
This is preparatory work to preserve formatting information from the
original source code (empty lines and comments), but no change of
behavior is expected at this stage.
Whether to generate unparsers or not has non-trivial implications on the
language spec. For this reason, it does not make much sense to keep this
setting as a code generation option: it should instead be a property of
the language spec itself.
Enhance it to cover more DSL operations on big integers, and remove uses
of lexical envs, clearly not necessary to test big integers. This will
help transitionning the testcase to Lkt.
When debugging a testcase that contains multiple "*.lkt" files, it is
sometimes convenient to run the "lkt_compile.py" script on a single
source file. This commit extends this script to accept "lkt entry
points" as command line arguments.
