Fix parsing and evaluation of lambdas with args and operator associativity

[danieldickison]

Turns out parserBehavior.ts already had tests that were being skipped for lambdas with args. It references #65 but I'm not sure how that issue is related. This appears to be the root of issue #146

This should also fix incorrect operator associativity (see comment 894513849 and #153).

[danieldickison]

I've updated the PR with a fix — it parses an arg list in front of => by taking the previously parsed Expression and turning it into a new Parameters node, which extends the context when the lambda is called. This involved adding a new , operator and dropping the => operator precedence to the lowest possible.

It's a little bit hacky, but I think it works well given how the parser is organized. (In actual JS grammar, => is not defined as an operator, so would require some reworking if we want to mirror that parsing.)

[danieldickison]

In the course of testing this, I discovered another issue with the parser — it was incorrectly right-associating operators with equal precedence, and also mishandling (in a not-totally-clear way) some deeply nested trees. I rewrote Node.create_root to use the shunting yard algorithm to handle precedence and updated tests as appropriate.

[brianmhunt]

@danieldickison this looks excellent! I added a few comments (mostly of the linting and documentation variety) but in general I think everything here is fantastic. Thank you!

I'll wait for you to reply on the comments and we'll go from there, but I don't think anything here is a real blocker.

[brianmhunt]

Very minor note: out and ops are very similarly named, which might make them harder to read.

[danieldickison]

I feel like they present fairly distinctively in context, since out has an ascender while ops has a descender, and I can't think of good ones that aren't annoyingly long, but I'm open to other naming ideas!

[danieldickison]

@brianmhunt thanks for the review. I addressed each of your comments. Lmk how that looks to you.