802.11 radiotap dissector for IEEE80211_RADIOTAP on LINUX_SLL/SLL2 #2502

Summary

Part of #2460. LinuxSLL/LinuxSLL2 fall back to Raw for the
IEEE80211_RADIOTAP arphrd_type (803), whose protocol_type field isn't
an EtherType (see _ARPHRD_NOT_ETHERTYPE in
pcapkit/protocols/link/linux_sll.py). The header is preserved, nothing
crashes, but nothing is dissected either.

Scope

The widest of the five follow-ups in #2460: no 802.11 dissector of any kind
exists in this codebase, and radiotap is a prefix in front of the raw
802.11 MAC frame, not a replacement for it -- so this is really two new
protocols stacked, not one:

1. the radiotap header itself -- a variable-length, vendor-extensible
   prefix: a fixed 8-octet start (version, pad, length, present-flags
   bitmask) followed by a chain of further present-flags words (bit 31 of
   each signals "more follow") and then the fields the bitmask selects, each
   with its own alignment rule. No fixed length; the header's own length
   field is what bounds it.
2. the 802.11 MAC frame behind it -- frame control, duration/ID,
   address fields (2-4 of them depending on the ToDS/FromDS bits), sequence
   control, optional QoS/HT control, then the body (itself dispatching
   further by frame type/subtype: management, control, data).

Authoritative sources: the radiotap project's own field-by-field
specification (https://www.radiotap.org/) for (1), and IEEE 802.11
(the current base standard) §9 (MAC frame formats) for (2).

Given the scope, this likely wants its own further split once picked up
(radiotap header alone, with the 802.11 body kept Raw, as a first slice --
mirroring how #2460 broke its own five candidates apart). Not implemented
here -- tracked as its own issue per #2460's scoping.