Change Feed label 392 to bstr, representing an opaque series of bytes

[SteveLasker]

This attempts to resolve the balance between a generic string and a structured string for how issuers and verifiers can identify "a sequence of Signed Statements about the same Artifact.", as currently defined

Changing to bstr enables an issuer to set the Feed to be a sub, and it also allows an issuer to use other identifier formats.

There's a great suggestion to use sub, as part of the CTW (PR #108). And at first it looks fairly simple.

CWT_Claims = {
  1 => tstr; iss, the issuer that is making statements
  2 -> tstr; sub, the subject about which the statements are made, throughout this spec, this is also called feed.
 * tstr => any
}

The challenge is a CWT_Claim is far more expressive as defined

For an issuer and a verifier to clearly identify the specific artifact they are referencing with CWT_Claims, it would be both powerful and confusing for an issuer to specify which CWT_Claims properties they were using to identify the feed.

An issuer could add:

CWT_Claims = {
  1 => tstr; iss, the issuer that is making statements
  2 -> tstr; sub, the subject about which the statements are made, throughout this spec, this is also called feed.
  256 -> bstr; ueid, The Universal Entity ID 
  260 -> array; hwversion, the Hardware Version Identifier
  2395 -> uint; psa-security-lifecycle, PSA Security Lifecycle	
   * tstr => any
}

Using the text in PR #103, changing the Feed to bstr, makes it clear the Feed is:

Feed:
: a logical collection of Statements about the same Artifact.
For any step or set of steps in a supply chain there will be multiple statements made about the same Artifact. Issuers use the Feed to create a coherent sequence of Signed Statements about the same Artifact and Verifiers use the Feed to ensure completeness and non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the one(s) they are evaluating.
Fixe #11

[robinbryce]

LGTM

[SteveLasker]

Closing, in lieu of #108