feat(application): implement TLS/SSL and DTLS, sharing a record-layer base #2437

Is your feature request related to a problem? Please describe.
Wave 2 of the roadmap (docs/source/contributing/pep.rst). TLS/SSL and DTLS have no implementation — pcapkit/protocols/application/NotImplemented/tls.py is one of 20 identical 0-byte placeholders dating to the project's earliest commits, not a stalled design with prior art to reconcile.

Describe the solution you'd like
A shared record-layer base over the part TLS and DTLS genuinely have in common: the ContentType/legacy-version/length record header (RFC 8446 §5.1 for TLS, RFC 9147 §4.1 for DTLS) is byte-identical in shape between the two — a real, non-trivial shared surface, unlike ICMP/ICMPv6's thin case. DTLS's own divergence (explicit epoch + sequence number, and handshake-message fragmentation that a reliable TLS stream never needs) stays entirely in DTLS's own subclass, so the shared base doesn't force an awkward abstraction across the two.

Confirmed no structural conflict: Application (the base both would sit under -- TLS over TCP, DTLS over UDP) makes no transport assumption at all. It's generic over protocol/schema type parameters with a -1 sentinel for undissected trailing bytes, and never references TCP; HTTP's own class has zero TCP/reassembly coupling either, since all segment reassembly lives in pcapkit/foundation/reassembly/, orthogonal to the Application-layer classes.

DTLS's handshake-fragment reassembly should be a new subclass of the existing Reassembly base (pcapkit/foundation/reassembly/reassembly.py), which is already generic over packet-type/datagram-type/buffer-ID/buffer-type with tcp.py/ipv4.py/ipv6.py as concrete examples -- DTLS's buffer-ID would be the UDP 5-tuple plus epoch. This is a clean extension of existing infrastructure, not a new mechanism.

Describe alternatives you've considered
Building TLS alone first and deferring DTLS -- rejected per pep.rst's own framing: doing either half of the pair alone answers the shared-base design question twice.

Additional context
Discussion #251 separately notes DTLS currently blocks several SCTP PPID dispatch entries. Scope for a first PR: the record layer plus TLS 1.2/1.3 handshake framing (ClientHello/ServerHello/Certificate at the message-type level, not necessarily every extension); full extension parsing and DTLS's fragmentation/reassembly can be follow-ups within the same tracking issue.