In the past two-way bindings used to be interpreted as `foo = $event` at the parser level. In #54065 it was changed to preserve the actual expression, because it was problematic for supporting two-way binding to signals. This unintentionally ended up causing the TCB to two-way bindings to look something like `someOutput.subscribe($event => expr);` which does nothing. It largely hasn't been a problem, because the input side of two-way bindings was still being checked, except for the case where the input side of the two-way binding has a wider type than the output side.

These changes re-add type checking for the output side by generating the following TCB instead:

```
someOutput.subscribe($event => {
  var _t1 = unwrapSignalValue(this.someField);
  _t1 = $event;
});
```

PR Close #59002

Moves the fix for type checking the event side of two-way bindings behind a compiler flag so that we can roll it out in v20.

PR Close #59002

…way bindings

Follow-up to angular#59002. If a two-way binding is non-null asserted, only the property side was getting the assertion since the `$event` is synthetic. In practice this means that there's no way to non-null assert a two-way binding. These changes fix the issue by checking if the handler is asserted and applying it to the `$event` assignment.

…s when narrowed

After angular#59002, we started producing code like the following for the event side of two-way bindings:

```
someOutput.subscribe($event => {
  var _t1 = unwrapSignalValue(this.someField);
  _t1 = $event;
});
```

The problem with this approach is that if `someField` is narrowed, the type of `_t1` will be narrowed as well which will make `$event` unassignable. This came up when trying to roll out the changes from the previous PR internally.

These changes rework the approach by generating a function call instead. Now the TCB looks as follows:

```
someOutput.subscribe($event => {
  assignTwoWayBinding(this.someField, $event);
});
```

The `isSplitTwoWayBinding` function was a bit misleading, because it has side effects. Renames the function make it a bit more explicit.

PR Close angular#59002

In the past two-way bindings used to be interpreted as `foo = $event` at the parser level. In angular#54065 it was changed to preserve the actual expression, because it was problematic for supporting two-way binding to signals. This unintentionally ended up causing the TCB to two-way bindings to look something like `someOutput.subscribe($event => expr);` which does nothing. It largely hasn't been a problem, because the input side of two-way bindings was still being checked, except for the case where the input side of the two-way binding has a wider type than the output side.

These changes re-add type checking for the output side by generating the following TCB instead:

```
someOutput.subscribe($event => {
  var _t1 = unwrapSignalValue(this.someField);
  _t1 = $event;
});
```

PR Close angular#59002

…#59002)

Moves the fix for type checking the event side of two-way bindings behind a compiler flag so that we can roll it out in v20.

PR Close angular#59002