feat: use better QueryContext types for transactional triggers and validators

[wschurman]

Why

There is a use case for triggers to run in two phases:

1. Phase 1 runs during the transaction, and collects data for use in phase 2
2. Phase 2 runs after the transaction and operates on data collected in phase 1, but in a non-transactional context

The way to implement this is with a transactional trigger that calls queryContext.appendPostTransactionCallback for phase 2. That method is only available on EntityTransactionalQueryContext, and since we can be guaranteed that these types of triggers have a transactional query context we can type it as such.

How

Update the types to match reality.

Test Plan

yarn tsc

[codecov]

Codecov Report

Merging #136 (834009e) into master (4263cb9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #136   +/-   ##
=======================================
  Coverage   95.80%   95.80%           
=======================================
  Files          70       70           
  Lines        1810     1810           
  Branches      223      223           
=======================================
  Hits         1734     1734           
  Misses         75       75           
  Partials        1        1           

Flag	Coverage Δ
integration	95.80% <ø> (ø)
unittest	95.80% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...s/entity/src/EntityMutationTriggerConfiguration.ts	100.00% <ø> (ø)
packages/entity/src/EntityMutator.ts	98.20% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4263cb9...834009e. Read the comment docs.

[ide]

LGTM. I also could see a hypothetical use case for running code in cases without query contexts as well, since every Postgres query makes a transaction if it's not already in one.