feat!: add support for secrets in manifests

[protochron]

Feature or Problem

This adds support for secrets in wasmCloud application manifests. The
secrets themselves are actually secret references as outlined in
wasmCloud/wasmCloud#2190. Just like config, secrets can be specified at
the component or provider level or on a link.

Secret references themselves are actually implemented as an additional
kind of config stored in the same config data bucket. However, I opted
to implement a dedicated scaler for secrets that is largely a clone of
the existing ConfigScaler since the underlying data type is very
different than the arbitrary set of key/value pairs we use for config.

An example of what this looks like in a component is shown below:

spec:
  components:
    - name: http-component
      type: component
      properties:
        image: ghcr.io/wasmcloud/test-fetch-with-token:0.1.0-fake
        secrets:
          - name: some-api-token
            source:
              backend: nats-kv
              key: test-value
              version: 1
          - name: my-other-secret
            source:
              backend: aws-secrets-manager
              value: secret-name
              version: "be01a5fb-7ebb-4ae9-8ea0-0902e8940bc0"

This contains a breaking change to the way that we specify config on
links:

- type: link
  properties:
    namespace: wasmcloud
    package: postgres
    interfaces: [managed-query]
    target:
      name: sql-postgres
      secrets:
        - name: db-password
          source:
            backend: nats-kv
            key: myapp_db-password
            version: 1

Instead of using target_config and source_config, this renames them
to target and source respectively and adds keys for config and
secrets. The name of the target is now a key at the top
level of the target block, as seen above.

Related Issues

Release Information

Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

[brooksmtownsend]

One or two nits, and a bigger request around backwards compatible manifests. I found myself wondering if we needed a SecretScaler at all given that it's just a wrapper around configuration, but I think the separation is worth it at the very least for clarity and also for the future where we may do more complex things in response to a secret.

[brooksmtownsend]

I think it would be great to support the source_config and target_config properties here in order to support the current manifest format in a backwards-compatible deprecated way, e.g. if source_config is supplied but source is not, we fill in the source property at deserialization time. Thoughts?

[protochron]

Went ahead and updated the code so that both source_config and target_config transformed into the new representation. We'll have to figure out how to prepare to remove them entirely.

[brooksmtownsend]

@protochron and I have discussed the issue I brought up and decided that it would be best to transform manifests of the "old" source/target config format to the new automatically using wash. I think it would be nice to return a good error instead of a failed deserialization error / failed validation error if possible, in the case where folks are using the Wadm API directly instead of using wash (e.g. the operator, right?)

Let's see if we can use a wash plugin for the translation

[brooksmtownsend]

This PR largely looks really nice. Huge amount of changes, thanks for dealing with the copy/paste. Just a few requests, at least half are to remove comments/printlns

[brooksmtownsend]

LGTM! Just a test failing it seems