Move FelixConfiguration writes onto server-side apply on v3 clusters

[caseydavenport]

Description

Moves the FelixConfiguration write path onto server-side apply on v3-native clusters, and migrates every controller that writes FelixConfiguration onto it.

• The write path sits behind an interface with one implementation per API group, chosen by whether the operator is running against v3 CRDs.
• On crd.projectcalico.org/v1 it stays the existing merge patch, with an annotation recording what the operator last wrote so a user's edit is still detectable. That's the aggregated-apiserver case, where the operator writes v1 and users write v3 and managed fields aren't comparable across the boundary.
• On projectcalico.org/v3 writes go through server-side apply. Each write site owns a named set of fields, and per field it either defers to a user's edit, overrides it, or degrades the Installation status.
• Every controller declares the fields it drives on every reconcile, instead of only when the field is unset, because an owner that stops declaring a field deletes it.
• The policy sync socket path gets one owner that computes it from the ApplicationLayer, GatewayAPI, EgressGateway, and Istio resources together, so no controller can clear another's claim.
• Fields the operator wrote before this change are recorded as updates rather than applies. The apply path recognizes that older manager name, so the first apply that changes a value takes ownership back from it.

Behavior changes worth a look during review:

• eBPF mode gets written as explicitly disabled in cases where the operator previously wrote nothing at all.
• The eBPF kube-proxy health port is cleared when a cluster leaves eBPF mode, restoring Felix's own default instead of leaving it pinned at zero.
• The policy sync socket path is cleared once no feature needs it, where before it stuck around forever after the first write.
• On aggregated-apiserver clusters the operator only removes a field it has a record of having written, so a value inherited from before the upgrade is left alone.
• The application layer's TPROXY mode stays on the old merge path on purpose. Declaring it unconditionally would set it on clusters upgrading from before the field existed, which restarts Felix.

Remaining work is out of scope here: generated apply configuration types in place of hand-built payloads.