tools/internal/parser: check TXT records

[danderson]

Supports checking a single PR, as well as re-verifying the entire PSL.

---

Opening as a draft because I forgot about this until now :( and I need to re-read the change to make sure it's ready to go and doesn't have leftover debugging cruft.

The main portion of the change is in validate.go, and is hopefully commented enough to explain what's happening. Essentially, we do parallel DNS lookups to discover the _psl records, gather a list of all PRs to verify, an then fan out again with github API requests to inspect the PRs and see if they match the TXT record.

Note that when running the validation on the entire PSL, or doing frequent reruns, you need a github auth token in the environment as GITHUB_TOKEN, otherwise you'll get rate limited by github pretty much instantly.

[danderson]

It looks like github rate limits became much more aggressive since last time I used this code, previously I was able to run a check against the entire PSL a few time/hour. Now if I do that, I get limited almost immediately, even with authenticated requests. I'll see if I can make that more graceful, but in the meantime checking individual PRs works, since that's much lower load.

[danderson]

For now, I've put --online-checks behind a dev-only gate for whole-file revalidation, since that causes a lot of github API traffic, and that causes too many false positives from getting rate-limited. Consulting with @simon-friedberger I also lowered the concurrency for DNS record lookup to account for weaker home router DNS resolvers that don't like getting slammed with hundreds of qps of lookups 😅

Simon made a very good suggestion out of band: the github commit history actually has enough information to verify most TXT record values without asking github for anything! I have a prototype of this working now that cuts out >99% of the github API requests by using a local git clone. 5 PRs still need github queries to verify because the corresponding git commit does not list the PR number anywhere, so we cannot discover the PR<>commit data any other way than asking github.

This PR should still be good to go as-is for verifying individual PRs. I plan to send the optimization outlined above as a followup, along with some improvements to DNS querying to try and make whole-file revalidation more usable.