…ives (#60137)

The check that verifies that there are no duplicates in the directives array was only running after host directive matching since that was the only case when it can happen. After the upcoming changes that won't be the case anymore so these changes move it always run after directive matching.

I also did some additional cleanup by adding comments and by not lazily initializing the `allDirectiveDefs` array when matching host directives. The array is guaranteed to be defined since earlier in the function we verify that there's at least one def with host directives.

PR Close #60137

Some upcoming functionality won't work if we can't retrieve a directive definition from a class. These changes add a `throwIfNotFound` to `getDirectiveDef`, similar to `getNgModuleDef`, to avoid duplication in such cases.

PR Close #60137

…d components (#60137)

Updates `createComponent`, `ViewContainerRef.createComponent` and `ComponentFactory.create` to allow the user to specify directives that should be applied when creating the component.

PR Close #60137

Sets up the symbols used to power the upcoming `inputBinding` functionality.

I also fixed that `setDirectiveInput` was incorrectly only allowing strings for the `value` parameter.

PR Close #60137

Fixes that the `setDirectiveInput` function wasn't checkin if an input exists before writing to it which can lead to assertion errors.

PR Close #60137

…ts (#60137)

Adds the ability to bind to inputs on dynamically-created components, either by targeting the component itself or one of its directives. The new API looks as follows:

```ts
const value = signal(123);

createComponent(MyComp, {
  // Bind the value `'hello'` to `someInput` of `MyComp`.
  bindings: [inputBinding('someInput', () => 'hello')],

  directives: [{
    type: MyDir,
    // Bind the `value` signal to the `otherInput` of `MyDir`.
    bindings: [inputBinding('otherInput', value)]
  }]
});
```

This behavior overlaps with `ComponentRef.setInput`, with a few key differences:
1. `setInput` sets the value on *all* inputs whereas `inputBinding` only targets the specified directive and its host directives. This makes it easier to know which directive you're targeting.
2. `inputBinding` is executed as if it's in a template, making it consistent with how bindings behave for selector-matched components, whereas `setInput` executes outside the lifecycle of the component.
3. It resolves a long-standing issue with `setInput` where it wasn't possible to set the initial value of an input before the first change detection run.

Currently `inputBinding` is used only for `createComponent`, `ViewContainerRef.createComponent` and `ComponentFactory.create`, however it is going to be base for more APIs in the future.

PR Close #60137

Calling `setInput` while the component already has an `inputBinding` active can lead to inconsistent state. These changes add an error that will be thrown if that's the case.

PR Close #60137

…nents (#60137)

Adds the new `outputBinding` function that allows users to listen to outputs on dynamically-created components in a similar way to templates. For example, here we create an instance of `MyCheckbox` and listen to its `onChange` event:

```ts
interface CheckboxChange {
  value: string;
}

createComponent(MyCheckbox, {
  bindings: [
   outputBinding<CheckboxChange>('onChange', event => console.log(event.value))
  ],
});
```

Note that while it has always been possible to listen to events like this by getting a hold of of the instance and subscribing to it, there are a few key differences:
1. `outputBinding` behaves in the same way as if the event was bound in a template which comes with some behaviors like forwarding errors to the `ErrorHandler` and marking the view as dirty.
2. With `outputBinding` the listeners will be cleaned up automatically when the component is destroyed.
3. `outputBinding` accounts for host directive outputs by binding to them through the host. E.g. if the `onChange` event above was coming from a host directive, `outputBinding` would bind to it automatically.

Currently `outputBinding` is available only in `createComponent`, `ViewContainerRef.createComponent` and `ComponentFactory.create`, but it will serve as a base for APIs in the future.

PR Close #60137

#60137)

Reworks the `InputBinding` and `OutputBinding` functionality to be in object literals constructed in functions, rather than classes, because it seems like Terser was having a hard time tree shaking the classes when the functions weren't used.

PR Close #60137

…omponents

Builds on the changes from angular#60137 to add support for two-way bindings on dynamically-created components. Example usage:

```typescript
import {createComponent, signal, twoWayBinding} from '@angular/core';

const value = signal('');

createComponent(MyCheckbox, {
  bindings: [
    twoWayBinding('value', value),
  ],
});
```

In the example above the value of `MyCheckbox` and the `value` signal will be kept in sync.

…omponents (#60342)

Builds on the changes from #60137 to add support for two-way bindings on dynamically-created components. Example usage:

```typescript
import {createComponent, signal, twoWayBinding} from '@angular/core';

const value = signal('');

createComponent(MyCheckbox, {
  bindings: [
    twoWayBinding('value', value),
  ],
});
```

In the example above the value of `MyCheckbox` and the `value` signal will be kept in sync.

PR Close #60342