Support encrypted secrets

Summary of the new feature / enhancement

There are scenarios where a resource might export secrets. Using SecureString and SecureObject currently is insufficient as the contents are in clear text and the only contract is that the contents are redacted when traced.

Proposed technical implementation details (optional)

We can adopt CMS (Cryptographic Message Syntax) using public key encryption. This requires the user to provide a public key used for encryption. In this scenario, a resource that exports secrets would export it as a SecureString or SecureObject and when DSC receives it, would encrypt it using the given public key. When this config is applied, the user needs to provide the private key to decrypt the secrets which DSC would then pass to the appropriate resources. In this case, resources don't handle encryption/decryption directly and only DSC itself handles it.

Start by reviewing how DSC v3 handles SecureString and SecureObject values when resources export or receive secrets. Then investigate the proposed CMS public-key encryption flow, including where public and private keys would be supplied. Done requires an agreed design and an implementation plan covering encryption, decryption, and resource boundaries.