Live test zones should be self-hostable, not dependent on a maintainer's personal domain

[thegushi]

Summary

The walk-mode live tests added in this branch (libopendmarc/tests/test_dmarc_walk.c, testfiles/dmarcwalk.gushi.org.zone, testfiles/gushi.org.zone.inc) currently hardcode gushi.org and dmarcwalk.gushi.org as the test domains. That's fine today, but it ties test-suite autonomy to one maintainer's personal DNS staying available and unchanged indefinitely.

This is the same class of problem as #413 (filter tests depending on paypal.com/trusteddomain.org), just one level removed: instead of a stale assumption about a third party's DNS, it's a dependency on a maintainer's DNS. Anyone who wants to run --enable-live-tests without trusting that gushi.org stays put forever (an OS packager building in an isolated environment, CI run by someone other than Dan, or trusteddomainproject standing up its own dedicated test infrastructure) currently can't.

Proposal

• testfiles/dmarcwalk.gushi.org.zone is already a complete, self-contained, project-owned zone (own SOA/NS, every record exists only for these tests). It has no dependency on real-world content, so it's already portable in principle, just not in practice, since the domain name is a literal in the test source.
• Promote the domain name to a single configurable point (configure-time flag or environment variable read at test startup) instead of the hardcoded #define ZONE "dmarcwalk.gushi.org" in test_dmarc_walk.c. Anyone can then deploy the same zone file under a domain they control and point the test suite at it.
• This is scoped to the walk-mode fixture only. The gushi.org.zone.inc fragment (used by test_spf.c and parts of test_dns_lookup.c) tests against Dan's actual production SPF/DMARC records, not a portable fixture, and isn't part of this proposal; it would need new, purpose-built fixtures if it's ever made portable too.
• Worth considering alongside filter tests depend on live DNS records we don't control #413's fake-DNS-record approach for the paypal.com cases: a self-hostable zone and opendmarc_dns_fake_record() aren't mutually exclusive, they suit different needs (testing actual wire-format DNS resolution vs. fully deterministic offline tests).

Not urgent

No live test is broken today. This is a "make it switchable before we need to switch it" issue, worth doing if/when trusteddomainproject stands up dedicated test DNS, or if packager feedback asks for it sooner.

[thegushi]

Related gap found while reviewing other DNS edge cases: _dmarc.<domain> can legitimately be a CNAME to another name holding the actual v=DMARC1 TXT record (RFC 7489/9989 allow this). The old test_dns_lookup.c had a case for it (_dmarc.sf1.i.bcx.com, "Got DMARC record via CNAME"), but it was already commented out before the gushi.org rewrite in this branch, and wasn't revived since the original case depended on bcx.com infrastructure we don't control anyway.

Checked dmarc_dns_get_record()'s answer-section loop (libopendmarc/opendmarc_dns.c): it should handle this correctly as written, since it skips non-TXT RRs in the answer section and picks up the TXT record at the end of the CNAME chain. But nothing in the live suite currently exercises that path. Cheap to add once #432's self-hostable zone work happens, since a CNAME-fronted name can just be added to dmarcwalk.gushi.org.