program-type/BPF_PROG_TYPE_SCHED_CLS: Add netkit section

[NAME-ASHWANIYADAV]

Fixes #91

The attach-type table on the page already lists BPF_NETKIT_PRIMARY and BPF_NETKIT_PEER, but nothing explains what netkit is or how its semantics differ from qdisc-based attachment. This adds a ### netkit section under Attachment, after the tcx material, covering:

• what a netkit device pair is, and that programs run directly in the device's transmit path with no qdisc involved
• which end of the pair each attach type runs on (BPF_NETKIT_PRIMARY = host-to-container direction, BPF_NETKIT_PEER = the container's outgoing traffic)
• that both attach types are managed through the primary device (netkit_dev_fetch rejects the peer ifindex with -EACCES), so a workload inside the container cannot touch the policy attached to its own peer
• the netkit_action return codes, including one behavior difference from tcx worth calling out: unknown return codes drop the packet (the default: case in netkit_xmit) instead of being mapped to NEXT
• the per-end default policy and the blackhole variant for default-deny setups, plus the NETKIT_L3/NETKIT_L2 device modes

One note on the issue text: the default policy is actually NETKIT_PASS for both ends (netkit_new_link in drivers/net/netkit.c) - devices only drop by default when created with the blackhole policy, so the section describes default-deny as opt-in.

Everything is verified against drivers/net/netkit.c and include/uapi/linux/if_link.h at v7.2; the feature tag links to the netkit
introduction commit (35dfaad7188c, "netkit, bpf: Add bpf programmable net
device", v6.7).

[dylandreimerink]

That all looks good and accurate, thank you for picking this up 🙏

[NAME-ASHWANIYADAV]

Thanks for the merge, Dylan! 🙏