Adds support for transformations in cli.

Transformations is a new property of the destination spec, e.g.:

---
kind: source
spec:
  name: "xkcd"
  path: "cloudquery/xkcd"
  version: "v1.0.6"
  tables: ['*']
  destinations:
    - "postgresql"
  spec:
---
kind: transformer # new transformer kind
spec:
  name: "reverser"
  path: "localhost:7777"
  registry: "grpc"
  spec:
---
kind: destination
spec:
  name: "postgresql"
  path: "cloudquery/postgresql"
  registry: "cloudquery"
  version: "v8.0.7"
  write_mode: "overwrite-delete-stale"
  migrate_mode: forced
  transformers: # new transformer field
    - "reverser" # example transformer

  spec:
    connection_string: "postgresql://user:@localhost:5432/xkcd?sslmode=disable"

Multiple transformers are supported on a per-destination basis. Thus, each destination now constructs a transformer pipeline:

This transformer pipeline is not some accidental complexity. I'd love it if we could just for-loop and apply transformations sequentially, but we decided to make transformers asynchronous, so a transformation is not some function we can call: it's a goroutine that has recv & send semantics. I've abstracted the pipeline as simply as I could.

Note that, even if we'd just allow a single transformer per destination as an MVP, we'd still need a goroutine for it (and thus for the source Recv as well, which was a blocking for { ... } up until now). So this is as close to MVP as I can make it.

Current limitations

• Since the managed plugin system doesn't know about transformations yet, you can only use grpc at the moment.
• There's no concept of per-table transformers at the moment, so if a transformer is added to a destination, it'd sniff through every record processed by that destination. Rationale is to minimise MVP.
• I haven't added the Transformer kind to plugin-pb-go in managed plugin yet. There's a TODO in the code where Destination is used instead, but I think at the moment it doesn't affect anything.

Testing
In order to test this, you'll need a transformer. I've created https://github.com/cloudquery/cloudquery-private/tree/mariano/test-transformations which adds a test "reverser" transformer which you can go run . serve, and you should be good to test a sync with the yaml from above.

My testing

Syncs should continue to work as before if no transformations are added. Number of resources should not change between syncs (in case channel closing logic would lead to losing tails)

Adding a reverser transformer reverses the strings

I've also tried adding two reverses in sequence, which results in a regular sync (which tests that the pipeline system works). Note that currently you can't add the same transformer twice (we use a map, which elides all but one instance), so I hacked it to try this. We might want to allow it.