"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.

Bắt đầu với docs/auth/getting-started.md và tái hiện thiết lập AngularFire 7 bằng provideFirebaseApp(...) và provideAuth(...), sau đó thử đăng nhập bằng email/mật khẩu với TENANT_ID được cấu hình thông qua DI. So sánh thiết lập module này với thiết lập compat đã được ghi trong tài liệu và lần theo nơi giá trị tenant được kỳ vọng là sẽ được áp dụng. Hoàn tất khi đăng nhập theo tenant hoạt động hoặc giải pháp thay thế được hỗ trợ được ghi lại, bao gồm cả vai trò của FIREBASE_OPTIONS.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.