Remove EndOfFileTrivia and always collect trivia after top-level parsing

[Xanewok]

Checks boxes in #640 #638

This adapts ParserFunction to always attempt parsing the leading trivia after we had a succesful match. This has a nice side benefit of not overwriting tokens that would allow for more progress when collecting the final trivia (unlike previous [AttemptedParseRule, EndOfFileTrivia] sequence).

I'm not so happy with the resulting tree shape, however; IMO we should either:

1. return a "tree" that has both parents - the first one being the expected parsed rule node but also the second parent being the "leading trivia"
2. or at least introduce a notion of a virtual EndOfFile token that this final end-of-file trivia can belong to.

Otherwise, a lone, final LeadingTrivia child belonging to the rule node seems misplaced and it's not intuitive for me to find the remaining trivia in that place. I'm open for other suggestions!

[changeset-bot]

⚠️ No Changeset found

Latest commit: 206dc3f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[OmarTawfik]

Left a few questions/concerns

[OmarTawfik]

nit: are the whitespaces intended here? I wonder if we should update the name of the test if so.

[Xanewok]

I wanted to say that only a single comment is collected from the two; I've changed this to only_until_newline to better convey the meaning that we should only collect... well, until the newline, as part of the trailing trivia.