Introduce `commonware-glue` (?)

[patrick-ogrady]

There are a few mechanisms that would be great to maintain in the Commonware Library (like the DKG store in examples/reshare), however, they span multiple crates (and including in any of them is either impossible because of circular dependency [cryptography doesn't import storage] or just doesn't align with the function of a crate where it could be implemented [consensus shouldn't maintain a DKG player state store]).

We should consider where to put such mechanisms and it may make sense to create a cross-mechanism crate of sorts for this with "glue" code between a number of different crates (that is never meant to serve as a dependency elsewhere)? This would enable us to significantly decrease the size of examples/reshare.

[patrick-ogrady]

(We may ultimately conclude a DKG player store does make sense to put in consensus, but if not we should consider a path like this)

[clabby]

I'll leave it up to someone else to be the name guy, though this crate may be able to take over commonware-sync in spirit? Feels like a great place to put marshal/Marshaled, the Application interface, etc.

Having a place for the abstractions + mechanisms that fit between the application and all of the commonware crates could also be beneficial to offer standard test vectors for application implementors to use. For example if this crate also had a standard engine for launching all of the tasks for a given configuration, you could imagine exposing something like reshare's Plan.