Add RWMutex to protect concurrent map access in Set, Unset, and ForEach methods. Change New() to return *U pointer type for proper synchronization.

1. Why is this pull request needed and what does it do?

This PR fixes a data race in plugin/pkg/uniq that occurs during reload operations when multiple goroutines concurrently access the internal map without synchronization.

Problem: The Set(), Unset(), and ForEach() methods in plugin/pkg/uniq access a shared map without proper locking, causing race conditions detected by Go's race detector during TestReadme.

Solution: Added sync.RWMutex to protect all map operations:

• Set(): Uses RLock for existence check, then Lock for write with double-check pattern
• Unset(): Uses Lock for safe deletion
• ForEach(): Uses Lock for iteration and modification
• Changed New() to return *U pointer instead of U value for proper synchronization

Testing: All tests pass with -race flag enabled, including the previously failing TestReadme.

2. Which issues (if any) are related?

#7703

3. Which documentation changes (if any) need to be made?

None. This is an internal package (plugin/pkg/uniq) with no user-facing documentation.

4. Does this introduce a backward incompatible change or deprecation?

Yes, this introduces a breaking change:

New() now returns *U instead of U.

Internal compatibility: ✅ All CoreDNS internal usage (plugin/metrics and plugin/ready) is fully compatible because they use type inference (u := uniq.New()).

External impact: ⚠️ Third-party plugins using explicit type declarations may be affected:

var u uniq.U = uniq.New()  // ❌ Won't compile with new version
var u = uniq.New()         // ✅ Works (type inference)

Since plugin/pkg/uniq is an internal package not intended for external use, I believe this breaking change is acceptable. However, if backward compatibility is required, I can provide alternative solutions (e.g., deprecation period or dual API).