feat(material/dialog): Make MatTestDialogOpener better

Start with MatTestDialogOpener and the existing dialog-opener.spec.ts, then read the referenced OverlayContainer implementation and its testing-overlay comments. Investigate how fixture querying, harness loading, and afterClosed handling currently work. Done should provide a defined, tested approach that makes dialog content queryable from the fixture and simplifies checking the closing result.

Feature Description

There's currently no supported way to render an overlay (and therefore a MatDialog) inside a component fixture during unit tests. Because overlays are attached to an OverlayContainer appended to document.body, they live outside the fixture's root element, which means:

fixture.debugElement.query(...) finds nothing inside the dialog.
Loading harnesses requires TestbedHarnessEnvironment.documentRootLoader rather than the standard fixture loader.
Asserting on dialog content requires reaching back to the document, e.g. getDebugNode(document.body) as DebugElement.

MatTestDialogOpener helps instantiate a dialog-hosted component (and removes the boilerplate of manually providing MatDialogRef + MAT_DIALOG_DATA mocks), but it doesn't address querying, and testing the close result still needs a manual async flush.

I prototyped a custom OverlayContainer that appends the container into the DOM, but it expects the fixture to be the first element in body:

import { OverlayContainer } from "@angular/cdk/overlay";
import { Injectable, Provider } from "@angular/core";

@Injectable()
export class FixtureOverlayContainer extends OverlayContainer {
    protected override _createContainer(): void {
        super._createContainer();
        document.body.children[0].appendChild(this._containerElement);

    }
}

export function provideFixtureOverlayContainer(): Provider[] {
    return [{
        provide: OverlayContainer,
        useClass: FixtureOverlayContainer
    }]
}

providing it in the test environment removes the need of documentRootLoader, the "simple" loader is enough, but querying the fixture still finds nothing. I found some comments about testing overlay plans I expect it could be useful in this case.

MatTestDialogOpener helps with creating the component, but testing the closing result still requires a manual await step, like
await firstValueFrom(fixture.componentInstance.dialogRef.afterClosed());. I found in the dialog-opener.spec.ts a setTimeout is awaited, there could be an async method baked into the MatTestDialogOpener class.

It would be really nice, if there would be a TestOverlay which creates the dialog in the fixture, so no const bodyDebug = getDebugNode(document.body) as DebugElement; is needed for querying components inside the dialog. Or at least have some methods getting the debugElement of the newly created component.

Use Case

Make testing components meant to be used inside MatDialogs more convenient, not like this