Separate Trusted Services interface into its own crate

Our interface for interacting with the Trusted Services is currently baked into the Parsec service - the bindings for the C API are generated at service build time, along with the linking commands and so on. This is acceptable for the moment since the TS provider isn't intended for use yet (primarly because there are no platforms to support it). In the long run, however, it will be necessary to pull this piece of code out into its own crate/repo, much like we've don with the psa-crypto and the tss-esapi crates.

Ideally, there should be two separate crates spun out - one for the lower, FFI layer, and one for the abstracted, Rust-native interface we currently use in Parsec. The FFI crate could also contain pre-generated code to handle the RPC contracts written in protobuf/packed-C etc. Similar to the approach in the other crates, bindings for specific platforms can be pre-generated and commited to the tree when the TS client interface can be considered stable enough.

The current contents of src/providers/trusted_service/context/ would form the basis for (part of) the new crate, though it only abstracts over the crypto service for now.

This separation will also allow the new crates to evolve in their own rhythm and direction, allowing the community to add and use support for other services or encoding schemes not needed by Parsec.

parallaxsecond / parsec

Separate Trusted Services interface into its own crate #407