feat(CdkPortalOutlet): Introduce signal-friendly way to track portal attachment/detachment

### Feature Description

Tracking if a portal is attached/detached within a `CdkPortalOutlet` can be cumbersome, it would be a nice improvement to expose the attached portal or the attachment/detachment state as a signal.

### Use Case

We create a component portal on a parent element which will get components attached by its children. In case a component is attached, I need to adapt the styling.

Lets take the following example, my expectation initially was that the class will be set correctly.

```
myOutlet = viewChild(CdkPortalOutlet);

// outlet gets passed to children which will attach components

```
The issue though is that `myOutlet` is only initialized once and changes to the `portal` within are not tracked if there is no other event triggering change detection at the same time. So the code above can actually get out-of-sync.

The best workaround I found is to manually keep track of the attachment/detachment.
This is more complex than it should be and my example is also possibly missing cleanup code

```
myOutlet = viewChild(CdkPortalOutlet);
isOutletAttached = signal(false);

effect(() => {
this.myOutlet()?.attached.subscribe(() => {
this.isOutletAttached.set(true);
this.myOutlet().attachedRef?.onDestroy(() => this.isOutletAttached.set(false));
});
});

...
```

Ideally one of the internal members of the `CdkPortalOutlet` should expose a signal which can be used.

```
myOutlet = viewChild(CdkPortalOutlet);

// multiple options
...
...
...
```

Start with the CdkPortalOutlet entry point named in the issue and trace how its portal attachment and detachment state is exposed. Compare the proposed signal forms against the existing attached and attachedRef behavior. Done means consumers can react to attachment changes without manual subscriptions or cleanup, with the chosen API and its behavior documented by the project’s tests.

Written by the indexing model from the issue text.