feat: Multi-yield transformers

[Spacerat]

Summary of Changes

This makes it possible for transformers to yield multiple records. This allows transformers to enrich records by yielding additional data.

For example, if my company has a convention for documenting owners in table descriptions using @owner: name, a transformer in the table extraction pipeline could yield TableOwner (as well as the original record).

A small knock-on effect of this approach was that, since ChainedTransformer now always returns an iterator, I code was expecting a ChainedTransformer to return a value, I had to wrap it with next(..., None).

Tests

I added an integration test which exercises the task and chained transformer changes end-to-end. This is pretty much copied out of the test I wrote for this in my own codebase. I know it doesn't quite fit the existing convention, but, I do think having end-to-end tests like this can be useful anyway. Would be interesting to get thoughts.

Documentation

I updated the README.

CheckList

Make sure you have checked all steps below to ensure a timely review.

• PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.
• PR includes a summary of changes.
• PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain docstrings that explain what it does
• PR passes make test

[feng-tao]

will take a look this pr early next week.

[Spacerat]

@feng-tao I just fixed the conflicts and sorted the imports so this passes CI again. Anything else I can do to help get it in?

[feng-tao]

sorry for the wait, will look at this week.

[feng-tao]

lgtm overall