[Draft] Expose unprotected headers, additional protected headers and payload to policy

[achamayou]

Illustrative PR for the purpose of discussion, showing:

• how unprotected headers and payloads can be exposed to policy (test_uhdr_policy, test_payload_policy)
• how to add an ephemeral Confirmation claim as an alternative to a did:x509 issuer, for attested payloads (test_cnf_kid)
• how to add a tss map in protected headers for attestation and collateral (test_tss_map)
• how to validate attestation and extract claims in registration policy (test_attestation_verification)

Note that unprotected headers must be only be used with great care in policy. It is necessary to authenticate them against either a trust anchor, or against a cryptographically secure fingerprint in the protected header. Using un-authenticated unprotected headers as inputs otherwise compromises the ability to audit policy execution.

The following protected headers are added to enable signing experiments:

CWT_Claims(15).cnf(8).kid(3) (https://www.rfc-editor.org/rfc/rfc8747.html#name-confirmation-claim)

A "tss" map with:
"tss" . "attestation"
"tss" . "snp_endorsements"
"tss" . "uvm_endorsements"

CWT_Claims.cnf.kid lets us bind x5chain[0] (PEM for now) and report_data in the attestation. We probably want to use CWT_Claims.cnf.COSE_Key ultimately, because the security properties will be same but the messages will be cleaner and X.509-free, but that requires a bit of refactoring.