Update generic structures

[OR13]

This PR build on #20 and attempts to clarify what is generic vc what is specific to RFC9162 encodings

[OR13]

This is the beginning of changes after #20

Substantial reordering an rewording follows...

[JAG-UK]

I've separately approved #19 and #20 in other PRs.Starting review from this point

[JAG-UK]

Mostly improves on the earlier version, I like the generality it allows for.
A couple of larger questions in here amongst the suggestions

[JAG-UK]

I've separately approved #19 and #20 in other PRs.Starting review from this point

[JAG-UK]

This is interesting. I've been struggling with the suggested need for signing inclusion proofs - in large scale native MT systems (like Ethereum) the proof stands alone (given a published root) and signatures are pointless.

Are we saying here that actually 'signed inclusion proof' means 'a signed payload which includes a bunch of things including a stand-alone inclusion proof and some extra more semantically meaningful info about what the proof is for'? i.e. a complete SCITT sig?

[OR13]

(in the case of merkle trees) a signed inclusion proof is a signature over a merkle root, with the merkle audit path and other proof data in the unprotected header... such as that any party holding a leaf can recompute the root, and check the signature.

This allows parties to avoid storing or accessing a large shared database, such as a blockchain.

Which is also valuable to blockchain based approaches that want to be trusted by parties that won't verify the chain.... for example, a vendor might issued signed inclusion proofs, and then other vendors can trust the transparency service vendor without running all their backend, etc...