Route blame between Processor and Coordinator (#427)

* Have processor report errors during the DKG to the coordinator

* Add RemoveParticipant, InvalidDkgShare to coordinator

* Route DKG blame around coordinator

* Allow public construction of AdditionalBlameMachine

Necessary for upcoming work on handling DKG blame in the processor and
coordinator.

Additionally fixes a publicly reachable panic when commitments parsed with one
ThresholdParams are used in a machine using another set of ThresholdParams.

Renames InvalidProofOfKnowledge to InvalidCommitments.

* Remove unused error from dleq

* Implement support for VerifyBlame in the processor

* Have coordinator send the processor share message relevant to Blame

* Remove desync between processors reporting InvalidShare and ones reporting GeneratedKeyPair

* Route blame on sign between processor and coordinator

Doesn't yet act on it in coordinator.

* Move txn usage as needed for stable Rust to build

* Correct InvalidDkgShare serialization

docs/DKG Exclusions.md

@@ -0,0 +1,23 @@
+Upon an issue with the DKG, the honest validators must remove the malicious
+validators. Ideally, a threshold signature would be used, yet that would require
+a threshold key (which would require authentication by a MuSig signature). A
+MuSig signature which specifies the signing set (or rather, the excluded
+signers) achieves the most efficiency.
+
+While that resolves the on-chain behavior, the Tributary also has to perform
+exclusion. This has the following forms:
+
+1) Rejecting further transactions (required)
+2) Rejecting further participation in Tendermint
+
+With regards to rejecting further participation in Tendermint, it's *ideal* to
+remove the validator from the list of validators. Each validator removed from
+participation, yet not from the list of validators, increases the likelihood of
+the network failing to form consensus.
+
+With regards to the economic security, an honest 67% may remove a faulty
+(explicitly or simply offline) 33%, letting 67% of the remaining 67% (4/9ths)
+take control of the associated private keys. In such a case, the malicious
+parties are defined as the 4/9ths of validators with access to the private key
+and the 33% removed (who together form >67% of the originally intended
+validator set and have presumably provided enough stake to cover losses).