Parsing Stack Enhancements

This issue collects some internal discussion regarding possible improvements to the parsing stack.

Slack discussion identified the following tasks (discussion has been summarized):

1. Iterate on syntax in the current parsing stack, so we can settle on something aesthethicaly pleasing for users.

   For example:

   • remove sum/records/prod keywords and just rely on RHS to be uniquely parseable { record }, (prod), | sum |. This would be helpful for the issue identified here

   • special unit type syntax, MaybeInt = Maybe Int (which would now be prod MaybeInt = (Maybe Int))

   • standalone derive statements are a bit verbose (rather why not just derive Eq, Json, PlutusData)

2. Update the formatter (I think that's basic stuff we need for automated code quality)

   • lbf format should be tested with a forall source. meaningOf lbf format source = meaningOf source,

3. treesitter grammar to have highlighting and symbol extractions in GH and editors for .lbf. files (improvement of life)

4. Align the parsing stack with something we fund robust and aligned with best practices (whilst making sure our error messages are amazing). Related issue comment

Start by reviewing the current parsing stack and the discussion linked from PR #117. Then inspect the formatter entry point, including the lbf format behavior for forall sources, and the existing .lbf grammar support. Done would require an agreed syntax, formatter preservation tests, tree-sitter highlighting and symbol extraction, and improved error messages.