Implement ActivateCredential key attestation

[ionut-arm]

A spec has been created under #370 to define the interface of the operations involved in key attestation. Protobuf protocols also exist, having been added in parallaxsecond/parsec-operations#34 .

This issue covers the implementation of the new operations across the stack, plus backending them to the TPM provider. The task can be split into:

• Adding the operations in the interface ( Add key attestation operations parsec-interface-rs#124 )
• Adding the plumbing for the operations in the Parsec service ( Activate credential #558 )
• Implementing the required functionality in the TransientKeyContext in the tss-esapi crate ( Add ActivateCredential support for TKC rust-tss-esapi#284 )
• Implementing the operations in the TPM provider ( Activate credential #558 )
• Implementing support for the operations in the Rust client ( Add activate credential attestation methods parsec-client-rust#100 )
• Implementing E2E testing for the new operations ( partially in Activate credential #558 , more tests added in Add ActivateCredential tests and fixes #560 )
• Implement proper error handling for the new operations ( Add error handling to ActivateCredential #562 )

[ionut-arm]

While implementing some tests for the ActivateCredential attestation mechanism in the TSS crate I realized an important caveat that I don't think was very clear to me back when first pitching this implementation.
The API design that I came up with for ActivateCredential attestation accepts not only a key to be attested, but also an (optional) key to attest with. This latter one is at the core of the caveat. The issue is that the key used to attest with can't be just any decryption key, like the ones that Parsec clients can generate at any time and decrypt stuff with, but rather they must be restricted decryption keys, meaning they can't be used for decrypting stuff from users in general. Such keys are generally used to store other keys as its children, thus generally called Storage Keys, but using them for stuff like attestation via ActivateCredential is also allowed. The broader point is: decryption keys generated by Parsec clients via PsaGenerateKey cannot be used like this, so it's essentially impossible to create a chain of attestations in this way.
Two options here, looking forward are:

• we implement a feature through which the admin can provision some keys and declare them in the config file, and these keys can be used by all clients to attest stuff (via a name?)
• we implement a new operation specific to the TPM which would allow clients to provision Storage Keys like they would any other key, for the sole purpose of using them with ActivateCredential
  These two options need not be exclusive.

Following a discussion on the Slack channel, the most sensible approach seems to be to the latter approach, but again with a generic operation (rather than TPM-specific). However, since there is no need or explicit use-case (for now) for supporting attestations with user-generated keys, this feature will be parked.

[ionut-arm]

One item that was not covered by the initial checkboxes was error handling. Currently errors occuring during the ActivateCredential call are mapped to PsaErrorCommunicationFailure. Ideally, the relevant ones should instead map to more descriptive error codes.

A bit of design brainstorming should go on before this is put into practice to discuss questions like: "do we want these new error codes to be specific to key attestation?".

A checkbox for this work should now appear in the top comment.