Allow external controller to deploy ksvc using SSA

This issue was originally reported in slack (https://cloud-native.slack.com/archives/C04LMU0AX60/p1705591161751469) and knative serving & networking meeting.

This issue should be fixed when the pod go struct will have the right annotations. (https://kubernetes.slack.com/archives/C0123CNN8F3/p1705594643726679)
Those annotations are currently on k8s main branch but not in any release yet (at the time of the writing)

- Main: https://github.com/kubernetes/api/blob/master/core/v1/types.go#L3549-L3550 (present)
- v0.29.1: https://github.com/kubernetes/api/blob/v0.29.1/core/v1/types.go#L3501 (missing)
- v0.30.0-alpha0: https://github.com/kubernetes/api/blob/v0.30.0-alpha.0/core/v1/types.go#L3501 (missing)

kube PR: https://github.com/kubernetes/kubernetes/pull/121759

## In what area(s)?

/area API
/kind spec

## What version of Knative?

Probably all

0.9.x
0.10.x
0.11.x

## Expected Behavior

While creating a knative service resource using SSA (server side apply), the different apply that contains the same knative spec shouldn't change the object & should not trigger additional reconciliation loop.

More specifically, knative serving mutating webhook should patch independently the field it cares about.

## Actual Behavior

While creating a knative service resource using SSA (server side apply), the spec is modified by the knative serving mutating webhook. Those modifications change the resourceVersion and trigger indefinitely the reconciliation loop.

The granularity of the managedField is not fine enough, which is probably causing the endless loop

## Steps to Reproduce the Problem

N.A

Start with the Kubernetes core/v1/types.go annotations referenced in the issue and review kube PR 121759 to understand the dependency. Then trace Knative Serving's mutating webhook behavior for server-side apply and verify that repeated applies do not change the object or trigger another reconciliation loop.

Written by the indexing model from the issue text.