"TENANT_ID" DI token is ignored when using the new AngularFire 7 / Firebase 9 methods

While attempting to upgrade from firebase v8 to v9 as described here: https://firebase.google.com/docs/web/modular-upgrade

I was led to upgrade AngularFire to version 7 and migrate all my authentication logic to the new method in order to benefit from the modular tree-shaking. As part of this I needed to make several changes to my code, some examples of these changes for context:

Module Imports Before:
```
import { AngularFireModule } from '@angular/fire/compat';
import { AngularFireAuthModule } from '@angular/fire/compat/auth';

@NgModule({
imports: [
AngularFireModule.initializeApp(environment.firebaseConfig),
AngularFireAuthModule,
]
})
```

Module Imports After:
```
import { provideFirebaseApp, initializeApp } from '@angular/fire/app';
import { provideAuth, getAuth } from '@angular/fire/auth';

@NgModule({
imports: [
provideFirebaseApp(() => initializeApp(environment.firebaseConfig)),
provideAuth(() => getAuth()),
]
})
```

onAuthStateChanged Before:
```
import { AngularFireAuth } from '@angular/fire/compat/auth';

constructor(private auth: AngularFireAuth) {
this.auth.onAuthStateChanged((firebaseUser: firebase.User | null) => { ... });
}
```

onAuthStateChanged After:
```
import { Auth } from '@angular/fire/auth';
import { onAuthStateChanged, User } from "firebase/auth";

constructor(@Optional() private auth: Auth) {
onAuthStateChanged(auth, (user: User | null) => { ... });
}
```

After migrating to the new approach it seems that the "TENANT_ID" I provided (see snippet below) is now completely ignored, it isn't even requested at any time by AngularFire during the initialization whereas this was working fine with the old approach.

```
providers: [
{ provide: FIREBASE_OPTIONS, useValue: environment.firebaseConfig },
{
provide: TENANT_ID,
useFactory: (config: ConfigService) => {
return config.getTenantFirebaseId();
},
deps: [ConfigService]
}
]
```

You can see I'm also providing "FIREBASE_OPTIONS" since this was mentioned in the documentation, though I am confused about the purpose of this token since I already passed `environment.firebaseConfig` into the `initializeApp` call in the module imports.

Is this a bug or is there a different way to do this now? I could not even find the word "tenant" mentioned in the recent documentation. I am concerned about this as Google have made it clear that they will not support the old compat approach forever, but I cannot migrate without support for multi-tenancy.

I must also add that the AngularFire documentation needs to be updated. If we are supposed to use this new approach then why is it not documented here: https://github.com/angular/angularfire/blob/7.4.1/docs/auth/getting-started.md ?

### Version info

**Angular:** 14.1.0

**Firebase:** 9.10.0

**AngularFire:** 7.4.1

### How to reproduce these conditions

Create an AngularFire 7 app following the documented setup steps using the new `provideFirebaseApp(...)` syntax instead of the old `AngularFireModule.initializeApp(...)` syntax. Specify a tenant ID using the DI token "TENANT_ID". Attempt to sign in with any method (eg. email and password). Result: Cannot sign in due to missing tenant ID. AngularFire is trying to sign in without specifying the tenant ID which leads to a 400 Bad Request from firebase since the used sign in method is not enabled (we only have sign in methods enabled on a per tenant basis). This same process works as expected when using the old approach prior to firebase v9 and the use of modular imports.

### Expected behavior

AngularFire should respect the "TENANT_ID" injection as it did before or clearly explain what the alternative is.

### Actual behavior

AngularFire ignores the "TENANT_ID" injection and as a result Firebase auth is unusable.

Start with docs/auth/getting-started.md and reproduce the AngularFire 7 setup using provideFirebaseApp(...) and provideAuth(...), then attempt email/password sign-in with TENANT_ID configured through DI. Compare this modular setup with the documented compat setup and trace where the tenant value is expected to be applied. Done means tenant-scoped sign-in works or the supported alternative is documented, including the role of FIREBASE_OPTIONS.

Written by the indexing model from the issue text.