add cancellation support to async iterable iteration

[yaacovCR]

When the abort signal is triggered, any pending .next() calls should return immediately, and the underlying async iterables .return() method should be called

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	fe08f46
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/6728bc577a7a610009037eaa
😎 Deploy Preview	https://deploy-preview-4274--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

[yaacovCR]

NOTE: will potentially rename PromiseCanceller to something more generic in a later PR.

Something like: AbortSignalListener, and potentially even the methods of the class can be switched to functions which take a shared AbortSignalListener.

[JoviDeCroock]

ExecutionOrchestrator could be an over-arching term. It essentially listens for a signal and tears down execute

[yaacovCR]

This PR has been updated:

1. to be a little less clever => with cancellableIterable(), we no longer call the underlying iterable's .return() method automatically. This is tricky to get exactly right -- users of the functions would have to know not to call .return() themselves -- and is also not necessary in our case, because as soon as the iterable errors with any error, including an abort error, our code calls .return() already.

2. to be a little less sloppy => we now call .disconnect() hopefully everywhere required to remove all added event listeners.