Fix domain name encoding to Latin1 and canonical case folding to ASCII-only

[Hemsby]

Bug

SerializeDomainName/DeserializeDomainName use Encoding.ASCII, which
silently corrupts any label byte >= 0x80 to ? on write and throws on
read. DNS wire-format labels are octet strings (RFC 1035), not restricted
to ASCII, so a well-formed name containing such a byte is currently
mishandled rather than round-tripped faithfully.

Fix

Encoding.Latin1 maps codepoints/bytes 0-255 one to one, a strict
superset of ASCII, so this is a no-op for every name that worked before
and only changes behavior for the previously-broken case.

A related, currently-latent bug this would otherwise expose

RFC 4034 section 6.2 canonical form requires lowercasing ASCII A-Z only,
but CanonicallySerializedResourceRecord.Create and
DnsNSECRecordData.CanonicalComparison both used
string.ToLowerInvariant(), which performs full Unicode case folding and
would change the byte value of Latin-1 supplement codepoints (e.g. 0xC0 to
0xE0). That corrupts the bytes that feed into RRSIG generation and NSEC
canonical ordering for such names. This has been dormant because those
bytes could never survive the ASCII round-trip to reach this code - fixing
the encoding without also fixing this would have introduced a live
signature-correctness bug for real inbound names.

Added DnsDatagram.ToLowerInvariantAscii, which folds only A-Z and leaves
every other byte untouched, and used it at both call sites.

Testing

Verified against RFC 4470's own worked example and several edge cases via
direct testing of the serialize/deserialize round trip and canonical
comparison for names containing bytes outside the ASCII range.

[ShreyasZare]

Thanks for the PR. This fix looks good at a glance. Will study it soon and get it merged.