Fix FnCall

[OceanOak]

we accidentally got away from how we normally represent function calls in writtenTypes.dark, this pr fixes it.

• Grammar: Remove parens around the function call
• Grammar: Rename function_call to apply?
• WrittenTypes: use EApply and EFnName instead of EFncall
• Fix parser
• Get tests to pass
• Fix semantic tokens

#5321

[StachuDotNet]

This is looking great!

Two thoughts:

1. it'd be great to include, in the grammar.js, some /** commentary */ on expression and simple_expression noting why they exist and how they're different

2. to that end, I thought the logic there would be "some expressions are really clear where they start/end, and never need parens, and others might need parens () around them to help disambiguate.

But, these three being in simple-expression gave me pause:
$.dict_literal,, $.record_literal, $.enum_literal,

Ok well for dicts, the {} make it clear I suppose. and for records, they have the {} and just a quick label to the left. and enum literal, similar to record literal (esp since even for 1 arg we require the () to wrap, for now). So, in writing this, I've sort of reconsidered. But, it gave me pause - "isn't there chance for ambiguity when passing one of these into a fn argument?"

---

Anyway, this is mostly a request for some such commentary in grammar.js, and wanted to think through those 3 cases.

[StachuDotNet]

also, I think the answer to

Grammar: Rename function_call to apply?

is yes

[OceanOak]

isn't there chance for ambiguity when passing one of these into a fn argument?

I've added more tests around this, and a todo to reconsider having enums as a simple_expression. maybe once we remove the parentheses around enum field, it could cause ambiguity (not sure). Thanks for pointing it out

[StachuDotNet]

great work here!