feat(core): allow building trigger bodies via query builder - #8373

…8327)

Conditions on a polymorphic relation like `{ imageable: { title: 'foo' }
}` used to resolve only against the first target, so properties of the
other targets threw as unknown. Now they go to the targets that define
all the queried properties. A single matching target is joined directly.
When several match, each is left joined and the branches are combined
with `$or`, with each branch also requiring the target PK to be
non-null.

```ts
// only `Article` has `title`
await em.find(Image, { imageable: { title: 'foo' } });
// both `Product` and `Article` have `name`
await em.find(Image, { imageable: { name: 'shared' } });
```

Primary key conditions follow the same rule. A PK that every target
defines, like `{ imageable: { id: 1 } }`, is still compared on the FK
column without a join and matches any type. A PK only some targets
define, like `{ source: { code: 7 } }`, joins those targets so the type
gets checked too.

Ordering still resolves against the first target only. MongoDB throws
for these conditions, same as for other non-reference polymorphic
conditions.

The branch includes a merge of `master` (#8326, #8328), so those commits
show up here until `master` is merged into `next`.

MongoDB has no joins, so conditions like `{ author: { name: 'Jon' } }`
or `{ tags: { name: 't' } }`, and any condition on an inverse side like
`{ books: { title: 'b1' } }`, were sent as is and silently matched
nothing. When one of them sat in an `$or` next to a matching branch, the
query looked like it worked. They now throw an error that names the
relation.

Conditions by PK keep working. The serialized PK is now supported as
well: `{ author: { id: hexString } }` used to match nothing and now
compares the reference like `{ author: { _id } }` does.

This targets `next`, because queries that looked like they worked before
(a relation condition inside an `$or` that other branches satisfied) now
throw.

…8333)

Ordering by a property of a polymorphic relation target used to resolve
only against the first target, so `{ imageable: { title: 'asc' } }`
threw when `title` lives on another target. Ordering by a property
several targets define only used the first target's column.

Each ordered property now goes to the targets that define it. A single
target is left joined and ordered by its column. With several targets,
each one is left joined (reusing joins from conditions on the same
targets) and rows are ordered by `coalesce(...)` of their columns, so
different types sort together:

```ts
await em.find(Image, {}, { orderBy: { imageable: { name: 'asc' } } });
// order by coalesce(`p1`.`name`, `a2`.`name`) asc
```

Relations and formulas of the targets use the first target that defines
them, and a PK that every target defines still orders by the FK column
without a join. Ordering by a property of the first target no longer
drops rows that point to other targets on non-nullable relations: it
used an inner join. That part is also fixed separately on master.

Limitations: the `orderBy` type only accepts properties all targets
define, so a property of a single target needs a cast. Distributing
`QueryOrderMap` over unions broke generic code in the core. When three
or more ordered fields alternate between different target sets, fields
with the same set are grouped, which can change their priority.

…columns (#8353)

Adds a `sequence: { startWith, incrementBy }` option for autoincrement
columns (decorators, `defineEntity` via `.sequence()`, `EntitySchema`).

```ts
@PrimaryKey({ sequence: { startWith: 1000, incrementBy: 10 } })
id!: number;
```

In `defineEntity`, a number is a shorthand for the start value:
`p.integer().primary().sequence(1000)`.

The options are applied when the column is created, and
`orm.schema.clear()` resets the counter back to `startWith`. The schema
generator never diffs them on any driver, so changing them on an
existing table produces no migration. Moving a live counter stays an
explicit migration.

That includes an autoincrement column added to an existing table. On
PostgreSQL and MySQL its existing rows get numbered from `startWith` as
well (PostgreSQL expands the `serial` column to a sequence created with
the options upfront). On PostgreSQL, a column that becomes autoincrement
starts at `startWith`, or continues after its highest existing value if
that is higher.

| Driver | On create |
|---|---|
| PostgreSQL `serial` | `alter sequence … start with … increment by …
restart` (via `pg_get_serial_sequence`) |
| PostgreSQL identity | `generated … as identity (start with … increment
by …)` |
| MySQL, MariaDB | `auto_increment = …` table option |
| SQLite, libSQL | row in `sqlite_sequence` |
| MSSQL | `identity(start, increment)` |
| Oracle | `generated by default as identity (start with … increment by
…)` |

Descending increments and start values past the default sequence bounds
(e.g. `startWith: 0`) work too. PostgreSQL and Oracle get the matching
`minvalue`/`maxvalue` for them.

MySQL, MariaDB and SQLite have no per-column increment, so `incrementBy`
throws a metadata error there. So does `sequence` on a property that
isn't autoincrement, or together with identity options written in
`generated`.

The entity generator reads the options back on PostgreSQL (serial and
identity), MSSQL and Oracle, and emits `sequence` in all definition
styles. MySQL, MariaDB and SQLite only store the next counter value, so
there's nothing to read there.

Two related changes:
- The schema comparator ignores identity option lists in `generated`
(`identity (start with …)`), so they follow the same create-only rule
instead of dropping and re-adding the column.
- MSSQL `clear()` picks the reseed value from
`sys.identity_columns.last_value` instead of the number of deleted rows.
This also fixes repeated `clear()` calls leaving the next id at 2 for
plain autoincrement PKs.

Closes #8350

Trigger body callbacks now receive a third `{ new, old, em }` argument. `new`/`old` map property names to the dialect's pseudo-row column references, and the callback can return a query builder, which is rendered without the `returning` clause (plus the `return` statement PostgreSQL requires). On MSSQL, inserts referencing the rows are rewritten to `insert ... select ... from inserted/deleted`.