Architecture: Definition of standard-interface to verifier

[FantasticoFox]

Requirements:

• A standard interface to retrieve data for the extension independent of the verifier which will exist in different implementations: e.g. library aqua-verifier-js / aqua-verifier-ts / aqua-verifier-go
• The verifier's library need to be able to print also to command line. So maybe we need a small command-line to for the data output digest?
• Other tools could use the output of the verifier for what ever...

Requirement to work for parallel revision verification:

If you verify a single revision, you can't do so if the previous revision had a signature or a witness event which got included in the current verification hash of the revision you're looking at. Hence: The context is given if the previous revision has signature or witness data. If they return true, you load that revision as well. The protocol is build in a way, which allows parallel verification. I would like to see this power utilized by the go-version of the verifier as go is optimal for parallel execution. This also requires that the verification structure / verification tree is first constructed, then all data is loaded, then all verification takes place (in parallel) and results are pushed out (also in parallel to be rendered in the front end).