Add shared library for writing resources across clusters

[scotwells]

What's changing

Adds a new pkg/downstreamclient package that centralises the cross-cluster resource management pattern currently duplicated across services.

Why it matters

Two services already implement this pattern independently:

• network-services-operator — uses MappedNamespaceResourceStrategy in internal/downstreamclient/ to write network resources into downstream clusters, mapping upstream project namespaces to ns-<uid> namespaces on the target
• compute — needs the same strategy to federate WorkloadDeployment objects to the Karmada control plane and project Instance objects back to management cluster namespaces

Without a shared library each new service that does cross-cluster writes copies the same code, with the risk of the namespace-mapping convention, anchor ConfigMap pattern, and upstream-owner labels drifting out of sync.

What's included

The pkg/downstreamclient package (moved and exported from NSO's internal package) handles:

• Namespace mapping — resolves upstream namespace → ns-<uid> on the downstream cluster
• Anchor ConfigMaps — tracks cross-cluster ownership so downstream resources are garbage-collected when the upstream owner is deleted
• Upstream-owner labels — consistent meta.datumapis.com/* labels so resources can always be traced back to their origin cluster, namespace, group, and kind
• TypedEnqueueRequestsForUpstreamOwner — generic controller-runtime handler that re-enqueues the upstream owner when a downstream resource changes

What's not changing

No existing behaviour changes. NSO's internal copy is unaffected until it chooses to migrate to this package. This PR is purely additive.

Consumers

Once tagged, the following services will import this package:

• go.datum.net/network-services-operator — migrate away from internal/downstreamclient/
• go.datum.net/compute — use MappedNamespaceResourceStrategy in the Karmada federation path