Encodings for elements to be hashed

[BasileiosKal]

First approach to close issue #96

Encodings suggestion of elements to be hashed (similar to the ones used by U-Prove).

This PR follows option 2 from the above issue, i.e., the encoding of elements to be hashed is described in a separate section and used implicitly throughout the document. See PR #95 for more context.

I also suggest that scalars, non-negative integers, and generic octet strings must always be prepended with their length while it is only recommended for EC points.

[BasileiosKal]

Updates proposed by @mikelodder7 and @andrewwhitehead during the WG call of 18/ 4/2022:

1. Lengths are extended to 8 bytes (for non-DST’s octet strings). Non-negative integers are also updated to be represented with 8 bytes, to be consistent with the representation of the lengths of octet strings (which are also non-negative integers).
2. The second paragraph is updated to make use of I2OSP (instead of zero-extensions).
3. The example is updated accordingly.

[mikelodder7]

LGTM now

[tplooker]

Multiple reviews and now approvals, open 10 days, discussed on latest WG call, merging