DTLS handshake-fragment reassembly #2440

Follow-up to #2437. That PR implements the DTLS record layer and handshake-message framing, including the fragment header (`message_seq`, `fragment_offset`, `fragment_length` -- RFC 6347 §4.2.2), but does not reassemble a handshake message DTLS has split across several records: `DTLS.read` decodes an unfragmented message (`fragment_offset == 0` and `fragment_length == length`) exactly as TLS would, and leaves a fragmented one's body as that single fragment's raw, undecoded octets, flagged via `DTLSHandshake.is_fragmented`.

What's missing

A new subclass of `pcapkit.foundation.reassembly.reassembly.Reassembly`, on the pattern of `pcapkit.foundation.reassembly.tcp.TCP_Reassembly` / `ipv4.IPv4_Reassembly`:

• Buffer ID: the UDP 5-tuple (source/destination address and port, protocol) plus the DTLS epoch, since sequence numbers and fragment offsets reset on an epoch change.
• Datagram type: one handshake message, keyed by `message_seq` within a buffer, assembled from its fragments ordered by `fragment_offset` once their `fragment_length`s cover `0..length` with no gap.
• Wiring into `pcapkit.protocols.application.dtls.DTLS` so a fragmented `ClientHello`/`ServerHello` (or any other handshake type) decodes once reassembled, rather than staying raw.

Why it's a separate PR

Reassembly is a foundation-layer mechanism with its own buffer-lifecycle and timeout concerns (see the existing IPv4/TCP reassembly classes), substantial enough that landing it alongside the record-layer dissector in #2437 risked neither landing cleanly. The dissector works correctly without it for the common case -- a `ClientHello`/`ServerHello` that fits one datagram never fragments.