LSP: Simplify parser and parse tree for LSP

[jmcardon]

This PR is a prelude that's necessary for further LSP work. It essentially simplifies the parser and moves a lot of the work that was previously done in the tokenizer + parser into the desugarer.

The parse tree is thus simplified significantly and far more independent of what we need for execution, which will help our LSP provide more accurate information on hover (the LSP analyzer is coming in a subsequent PR)

It also improves repl docs. That is, pre this pr:

pact>with-capability
(interactive):1:0: Unexpected input after expr, remaining tokens: [with-capability]
 1 | with-capability
   | ^^^^^^^^^^^^^^^

Post:

pact>with-capability
## with-capability

Use `with-capability` to apply the access to a specific capability to execute a body of code.
This function ensures that an elevated privilege—defined as a capability using a `defcap` code block—is present during the execution of the provided body of code. 

You can only call the `with-capability` function in the same module that contains the corresponding `defcap` declaration. 
If the token that grants permission to use the specified capability isn't found, the `with-capability`  evaluates the capability definition to install or grant the permission token. 
The permission token is automatically revoked after executing the code body. 
Nested `with-capability` calls for the same permission token detect the presence of the token and execute the body without reapplying the capability.

...

PR checklist:

• Test coverage for the proposed changes
• PR description contains example output from repl interaction or a snippet from unit test output
• (If Relevant) Documentation has been (manually) updated at https://docs.kadena.io/pact

Additionally, please justify why you should or should not do the following:

• Benchmark regressions
  • Benchmarks show no difference in execution speed
• Confirm replay/back compat (Ignore until core release)
• (For Kadena engineers) Run integration-tests against a Chainweb built with this version of Pact (Ignore until core release)

[rsoeldner]

I'm wondering what has caused the pairing-check gas increase?

[jmcardon]

I ran this code using master and adding (env-milligas) to the repl file. Loading it, here's the outcome:

Master

pact>(load "pact-tests/gas-goldens/pairing-check.repl" true)
"Loading pact-tests/gas-goldens/pairing-check.repl..."
"Set gas model to table-based cost model"
"Set gas limit to 150000"
Loaded module verifier, hash ArzjsOeeMDrskpTEaedsj0sfdXzv4RA3GP5oOTMnTTw
60012686
"Expect: success Pairing function check on test proof"
67003096

This PR:

pact>(load "pact-tests/gas-goldens/pairing-check.repl" true)
"Loading pact-tests/gas-goldens/pairing-check.repl..."
"Set gas model to table-based cost model"
"Set gas limit to 150000"
Loaded module verifier, hash xpLf2PRtsXDD940UWi0hkWWrcNb3G-teyE2gfSPQP-k
60012687
"Expect: success Pairing function check on test proof"
67003097

Notice the 1 milligas change. Likely changing the encoding changed the sizeOf which made us charge more gas, since we go through 1 more constructor for certain things.

It's just the module encoding changed. May have gotten microscopically bigger, but in return we dropped several constructors, which is a net win.

[rsoeldner]

isn't the module-hash based on stable encoding? It shouldn't change?

[jmcardon]

It's not based on stable encoding. It should change. It's based on our CBOR encoding.