common/domain: avoid pre-allocating untrusted lengths in the set reader

[AlexandrKhromov2005]

common/domain: avoid pre-allocating untrusted lengths in the set reader

readUint64Slice and readByteSlice read a length with binary.ReadUvarint and immediately
allocate a slice of that size (make([]uint64, length) / make([]byte, length)) before reading
the data. The length is untrusted — these readers parse serialized matcher data, reachable e.g.
from sing-box .srs rule-sets via AdGuard-format domain items — so a crafted input can declare a
huge length and either OOM the process on the allocation or panic with
makeslice: len out of range.

Found by fuzzing (go test -fuzz).

Fix

Read incrementally instead of trusting the length for a single allocation:

• []uint64 grows via append with a capped initial capacity, so a bogus length hits EOF while
  reading the elements;
• []byte goes through io.CopyN into a growable buffer, which only grows as bytes actually
  arrive.

Adds FuzzReadMatcher / FuzzReadAdGuardMatcher. Existing tests pass; valid data still decodes.

Companion to SagerNet/sing-box#4399, which fixes the same pattern in the .srs reader.