pxf: keep a comment that no entry follows, as protowire-go#283 does (TrailingComments, DatasetRow.LeadingComments) #176

protowire-go#283 (for Go's #279) changed where the parser puts a comment that no entry follows. cpp hasn't followed, so the differential against protowire-go fails on main and on every PR, starting with the release PR #175.

What Go does now (b3c210f)

• Document, Block and BlockVal gain TrailingComments. They hold the comments after the last entry, collected before the closing } or the end of input is consumed. Before, those comments were dropped at the end of a document. Before a block's }, they were dropped or carried out of the block onto the next entry.
• DatasetRow gains LeadingComments: the comments before the row's ( and inside the row. parseDatasetRow takes them itself, so the streaming reader files them as Parse does. Before, comments between rows went to the next directive or were dropped.
• CanonicalizeKeyed carries TrailingComments through the blocks it builds. When it drops a redundant key assignment that has no entry after it, the leading comments of that assignment become the block's trailing comments.
• Unchanged (Go's #282): comments inside a list still move after the list, and a row's same-line comment moves before the next row.

Measured

scripts/go_differential.sh with spec dd8e221:

• Go 8894b7b: no differences.
• Go b3c210f: ParseTolerant differs. Two lines differ, both in testdata/differential/rewrite/settings.pxf. cpp prints comment 12:3:259 # chords ... as a leading comment of recent, the entry after keymap { ... }. Go keeps it in keymap's TrailingComments, which the dumper doesn't print yet.

Done when

• cpp's AST has the four fields, and the parser, the streaming reader, CanonicalizeKeyed and the formatter use them as Go does.
• The differential dumpers on both sides print the trailing and row comments, and the run says no differences against Go main.
• Go's new tests (#283) are ported, including the three cases from protowire-go#279.