tools/internal/parser: add diff support

[danderson]

List.SetBaseVersion takes an older base List, and makes Block.Changed() reflect whether or not each block has changed compared to that base.

2 commits: one is the refactor to introduce the blockInfo struct, the other is diff.go and tests.

This is a building block that sets change information on a parsed list, which validations can then use to ignore unchanged elements. Generalized tree diff is an open academic research problem, so instead of doing that, this implementation takes some shortcuts by exploiting some special properties of the PSL, and by accepting some false positives (we mark as changed some things that didn't change, or changed in a way doesn't matter for validation) in exchange for simpler code and no false negatives.

I ran this logic against the last 50 PSL changes, here are the git diffs vs. changed parse tree nodes. Some noteworthy illustrations of the semantics:

• deleting a whole suffix block dirties the parent section, because the structure of its children has changed.
• deleting one suffix from a suffix block dirties the suffix block
• new suffix block is correctly detected as changed
• big Amazon suffix update precisely identifies the new/changed suffixes
• .aero update with no-op moves and new suffixes identifies the new/changed suffixes/comments, and ignores the semantically equivalent reordered ones.
• suffixes moved to a new block are dirtied. Arguably an example of a false positive, but IMO it's beneficial to flag suffixes that changed owners (e.g. to recheck TXT records).
• adjusting comments does not dirty unchanged suffixes.
• minor false positive in the newgtld section, the group marker is not separated from the first suffix block, so the timestamp update flags aaa as dirty. This is an easy adjustment to the newgtld output, and is on my TODO.

[simon-friedberger]

I merged your other PR. What is this conflict with and without toolchain?

[danderson]

That's an odd conflict, it seems like git should be able to resolve that without help. :shrug: I rebased this PR onto master and the conflict disappeared.

But actually looking at it more closely, I'm not sure why the toolchain directive got added. The code requires Go 1.22 for a few stdlib features, but forcing a minimum patch version of the toolchain is unnecessary. I suspect my emacs/LSP machinery added at some point during an automated edit. I added a commit to this PR to remove the toolchain directive and rely only on the go 1.22 directive.