Add support for TLV objects in the Segment Routing Header

## Background

TLV (Type Length Value) entries contain *optional* information that may be used by the node identified in the destination address packet. We currently support all components of the [Segment Routing Header](https://docs.rs/capsule/0.1.3/capsule/packets/ip/v6/struct.SegmentRouting.html) *except* for TLV entries. TLVs are particularly useful for [*HMAC*](https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-2.1.2) (The keyed Hashed Message Authentication Code) verification/security. [*PAD*](https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-2.1.1)-support (related to alignment) is necessary to the implementation.

---

From the [RFC](https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-2.1):

> A TLV provides meta-data for segment processing. The only TLVs defined in this document are the HMAC and PAD TLVs. While processing the SID defined, all TLVs are ignored unless local configuration indicates otherwise. Thus, TLV and HMAC support is optional for any implementation, however, an implementation adding or parsing TLVs **MUST** support PAD TLVs. Other documents may define additional TLVs and processing rules for them.
>
> TLVs are present when the Hdr Ext Len is greater than (Last Entry+1)*2.
>
> While processing TLVs at a segment endpoint, TLVs MUST be fully contained within the SRH as determined by the Hdr Ext Len. Detection of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field of the SRH, and the packet being discarded.
>
> An implementation MAY limit the number and/or length of TLVs it processes based on local configuration. It MAY:
> * Limit the number of consecutive Pad1 (Section 2.1.1.1) options to1. If padding of more than one byte is required, then PadN should be used.
> * Limit the length in PadN to 5.
> * Limit the maximum number of non-Pad TLVs to be processed.
> * Limit the maximum length of all TLVs to be processed.
>
> The implementation MAY stop processing additional TLVs in the SRH when these configured limits are exceeded.

Start with the existing Segment Routing Header implementation represented by capsule::packets::ip::v6::SegmentRouting and compare it with the linked RFC section on TLVs. Define how TLV and PAD entries should be represented and handled, including SRH-boundary validation. Done means TLV support covers the requested PAD alignment requirements and malformed entries cannot exceed the SRH Hdr Ext Len.

Written by the indexing model from the issue text.