clarify connection-based vs packet-based behavior

NetworkPolicy was originally intended to apply only to connection establishment, _not_ to every packet in a connection. However, like so many other things, this was not documented, and there is inconsistency between implementations currently. (For example, I know that kube-network-policies only checks NP on connection establishment, but ovn-kubernetes checks it on every packet.)

Only enforcing on connection establishment is more efficient, which is probably why we intended it to work that way. But there are users who definitely want the opposite semantics ("when I change policies, any existing connections that are no longer in-policy should be dropped"). That doesn't actually necessarily imply checking every packet: you could do it by deleting conntrack records for out-of-policy connections when policies change. (I think that might actually be what OVN does.)

We should probably say:
- ANP should use packet-based semantics.
- NP implementations _may_ use either semantics
- Future DNP or whatever should be consistent with ANP.

?

(cc @bowei re: https://github.com/kubernetes-sigs/network-policy-api/pull/303#discussion_r2201428943)

Start with the issue discussion and the linked Network Policy API pull-request discussion, then compare the described kube-network-policies and ovn-kubernetes behavior. Determine the intended semantics for NP, ANP, and future DNP, including how policy changes affect existing connections. Done means the agreed behavior is explicitly documented for implementers.

Written by the indexing model from the issue text.