Add crit (Critical Parameters) Header Support RFC 9052 §3.1

[aidangarske]

Description

What: The crit header parameter (COSE label 2) is an array of header labels that the recipient MUST understand in order to process the message. If any
label listed in crit is not recognized, the message MUST be rejected. wolfCOSE currently skips unknown header labels silently, including crit itself.

Why it matters: Consider a firmware update message with a custom header like "min-version": 3. The sender marks it critical so that old verifiers that
don't understand min-version will reject the message rather than installing a downgrade. Without crit enforcement, wolfCOSE would verify the signature,
ignore min-version, and allow the install — defeating the sender's intent.

RFC requirements (§3.1):

• crit MUST appear in the protected headers only — reject if found in unprotected
• crit MUST NOT be empty (reject empty arrays)
• Every label in the crit array MUST be understood and processed by the recipient
• Labels for headers defined in the core COSE spec (alg, kid, iv, etc.) SHOULD NOT appear in crit (they're always understood)
• crit itself MUST NOT be listed in the crit array

Implementation sketch:

1. During wolfCose_DecodeProtectedHdr, if label 2 is encountered, decode the array of int/tstr labels and store them (e.g., in a small fixed-size array
   in WOLFCOSE_HDR)
2. If crit is encountered in the unprotected headers, return WOLFCOSE_E_COSE_BAD_HDR
3. After all headers are decoded, verify every label in the crit list was actually present and processed. Any unrecognized label → reject with a new
   error code like WOLFCOSE_E_CRIT_UNKNOWN
4. Allow a caller-provided callback or allowlist so applications can register custom labels they understand

Affected functions: All verify/decrypt paths — wc_COSE_Sign1_Verify, wc_COSE_Sign_Verify, wc_COSE_Encrypt0_Decrypt, wc_COSE_Encrypt_Decrypt,
wc_COSE_Mac0_Verify, wc_COSE_Mac_Verify.