materialize/transactor: cancel load before Destroy() if commit fails

[mdibaiee]

Description:

• Currently there is a potential for deadlock if the transactor.Destroy() of a connector depends on cancellation of the Load phase. For example, this is the case for sqlserver and snowflake which wait for the database connection established for the load phase to be closed, and this closing of the connection blocks until existing operations are terminated. This can be reproduced by having a connector error during commit phase, while still processing its load phase (See this commit which emulates this situation).
• This happens as we do not cancel the load phase's context when there is a failure in the commit stage, this means any pending work in the load phase will never be terminated.
• This pull-request addresses this by allowing us to cancel the context used by the LoadIterator, so we can cancel it when an error is raised during commit phase

Test steps:

This has been tested by:

1. First reproducing the original issue by running a modified version of sqlserver which raises an error during commit phase, and ensures the Load phase is not terminated before this error is raised. This reliably reproduces the deadlock.
2. Then, the modified connector was updated to use this branch's transactor implementation, and the deadlock no longer happens. The load phase's context is cancelled and the error propagates up as expected, terminating the connector.

Documentation links affected:

(list any documentation links that you created, or existing ones that you've identified as needing updates, along with a brief description)

Notes for reviewers:

(anything that might help someone review this PR)

---

This change is 

[psFried]

LGTM % one nit.
I really appreciated the well-written PR description 👍

[psFried]

nit: It feels a bit "tricky" to me to lazily construct the context. IMO it would be better to initialize it when the LoadIterator is constructed in transactor.go. Technically, someone could call Cancel() before calling Context(), and it would be preferable for Context() to return an already-cancelled context in that case.

[mdibaiee]

@psFried refactored it

[jgraettinger]

LGTM too