Support ed25519 hashes as checksums

[larsvilhuber]

Proposed solution: use a public key crypto signature instead. ed25519 might be a good choice, as the tro-utils are already using openssl`, and because the hashes are quite short.

The data creator keeps the private key, the same way (or instead of) the PGP key. The public key gets incorporated into the JSON-LD TRS description.

The consumer of the TRO can verify the checksums of the files that they have in front of them using the public key. And, if they do get access to the confidnetial file (audit/ access to the RDC, etc.), they can also verify the other files. And the use case of flagging files that have changed remains unchanged (since that only relies on comparison of checksums, not on computing checksums.

• Allow for use of other algorithms to create checksums, encode in JSON-LD

Creation component

• implement ed25519 as a "private" checksum
• additional flag that chooses "private" or "non-private" (--private)
• if --private, a path to a private key must be specified
• if not --private, output is generated that signals that hashes are not privacy-preserving
• encode public key of chosen algorithm into JSON-LD

Verification component

• Read the required algorithm from the JSON-LD, search for public key in JSON-LD
• Edge case: software or public key absent for required public key: signal failure.