[Feature Request / Contribution Proposal] x5chain header helpers for Header / HeaderBuilder

Hi, and thanks for `coset` — it's been solid for COSE encode/decode.

Any **CoseSign1** consumer that embeds signing certificates in the **`x5chain`** header ([RFC 9360](https://www.rfc-editor.org/rfc/rfc9360), label 33) currently has to read/write the value manually via `Header.rest` / `value(...)`, even though `iana::HeaderParameter::X5Chain` is already defined.

For example, a typical verify flow needs to:

1. parse the header CBOR into an ordered certificate chain (leaf first; intermediates as concatenated DER);
2. validate that chain against trust anchors, optionally check CRLs, then verify the COSE signature with the validated leaf key.

Step (1) looks like a natural fit for `coset`; step (2) may not, given the crate's types-first / `no_std`-friendly design. I'm working on this for [corim-rs#56](https://github.com/veraison/corim-rs/pull/56) and would like maintainer input on scope before opening a PR.

My proposal is to split the work:

**Layer 1 (header parsing)** — add typed `x5chain` helpers on `Header` / builders: decode/encode the RFC 9360 wire shape, basic shape checks (non-empty chain, size/count limits, DER concatenation rules), but **no** PKIX, CRL, or crypto backend.

```rust
// on Header / HeaderBuilder
fn x5chain(&self) -> Result, CoseError>;
fn x5chain(self, chain: X5Chain) -> Self;

impl X5Chain {
fn from_cbor_value(v: &Value) -> Result;
fn to_cbor_value(&self) -> Value;
fn certificates(&self) -> &[Vec]; // DER, leaf first
}
```

**Layer 2 (PKIX trust verification)** — `CoseSign1::verify_with_x5chain` and PKIX/CRL checks need an X.509/crypto stack. That could be an optional `coset` feature, a companion crate, or left to callers. I have a prototype in corim-rs (`feature = "openssl"`), but I'm not asking to merge it as-is.

What do you think — should Layer 1 live in `coset`, and where would you prefer Layer 2? If Layer 1 sounds reasonable, I'm happy to send a PR for that first.

Start with the Header and HeaderBuilder entry points, then inspect the existing iana::HeaderParameter::X5Chain and Header.rest/value handling. Use RFC 9360 and the proposed X5Chain methods to define the Layer 1 boundary; done means typed encode/decode helpers with shape checks, without PKIX, CRL, or crypto verification. The payload mentions a corim-rs OpenSSL prototype for comparison.

Written by the indexing model from the issue text.