protocols: add DLT_NULL and DLT_RAW link-layer handlers

[JarryShaw]

Split out of #838 on the maintainer's instruction: "let's add the handlers (protocols) for DLT_NULL and DLT_RAW as part of wave 2/3 work in the work tracker then."

pcapkit/protocols/misc/pcap/frame.py:93-95 registers exactly three link types:

Enum_LinkType.ETHERNET: ModuleDescriptor('pcapkit.protocols.link', 'Ethernet'),
Enum_LinkType.IPV4:     ModuleDescriptor('pcapkit.protocols.internet', 'IPv4'),
Enum_LinkType.IPV6:     ModuleDescriptor('pcapkit.protocols.internet', 'IPv6'),

LinkType.NULL (0, DLT_NULL, BSD loopback — a 4-byte host-order AF_ family field ahead of the IP header) and LinkType.RAW (101, DLT_RAW — a bare IP packet, no link header at all) are genuine DLTs with no handler. That is what makes them unusable as a fallback for an unknown link-layer name, which is the ruling recorded on #838.

Scope: a handler per DLT, registered into Frame.__proto__, plus tests. DLT_NULL's family field decides IPv4 vs IPv6 and is written in the capturing host's byte order, so it cannot be read as fixed-endian. DLT_RAW needs the IP version nibble to pick IPv4 vs IPv6.

Not blocking #838 — that PR raises rather than guessing, which is correct with or without these handlers.

[JarryShaw]

Checkable blocker: scheduling — the maintainer assigned this to wave 2/3, in his words on #838: "let's add the handlers (protocols) for DLT_NULL and DLT_RAW as part of wave 2/3 work in the work tracker then."

So this is deliberately not started now, rather than unowned. It is not a dependency of #838 — that PR raises on an unresolvable link-layer name, which is correct with or without these handlers, and the ruling that produced it was made on exactly that basis.

Re-examine when wave 2/3 opens. blocked until then.

[JarryShaw]

wave 2/3 requests are saved in the pep.rst doc or discussion threads i think. not in the issues. we should move to the right place so that we dont block the original release criterion.

[JarryShaw]

Recorded, verbatim: "wave 2/3 requests are saved in the pep.rst doc or
discussion threads i think. not in the issues. we should move to the right place
so that we dont block the original release criterion."

Moved and closing. docs/source/pep.rst now sequences this as "Wave 2 or 3 —
handlers for the DLT_NULL and DLT_RAW link types", placed immediately before
the wave 3 paragraph and next to the LINUX_SLL entry, since all four are link
types the library enumerates but cannot parse. The entry carries the evidence from
this issue: __proto__ in pcapkit/protocols/misc/pcap/frame.py registers exactly
ETHERNET, IPV4 and IPV6, so a DLT_NULL (0) or DLT_RAW (101) capture
reaches no dissector.

Pushed docs-only to main as 6216de505. docutils parses the file with no new
severe messages — the Unknown interpreted text role errors it reports are
pre-existing Sphinx roles that bare docutils cannot resolve, present from
pep.rst:57 onward and not from these lines.