chore: Configuring an API Extractor report for the repo

[hiranya911]

This PR configures an API Extractor report for the project. This allows us to track changes made to our public API surface, and avoid accidental API changes.

• I've generated the initial API report, and checked it in at etc/firebase-admin.api.md. See the rendered markdown version at https://github.com/firebase/firebase-admin-node/blob/hkj-api-report/etc/firebase-admin.api.md
• In the future, whenever somebody wants to make a change to the public API, they must run npm run api-extractor:local to update the API report file locally, and push the changes as part of their PR. This provides us a signal whenever the public API is being intentionally updated. Also the markdown format makes it easier to review public API changes.
• If the developer forgets to update the API report file, or if the API is accidentally changed in a PR, CI will detect it and trigger a build failure.
• I'm using the firebase-namespace.d.ts file as the entry point for our API report. We cannot use index.d.ts until API Extractor supports some additional TS features:
  • [api-extractor] Support "import * as __ from __" for local paths microsoft/rushstack#1029
  • [api-extractor] Items exported with "export =" not included in the API report microsoft/rushstack#2338
• I've only implemented a minimal level of integration with API Extractor in this PR. I've intentionally disabled the d.ts rollup and other features to keep things simple. We can consider enabling these additional features in the future.

[bojeil-google]

Hey @hiranya911,
I am assuming any public API changes will still need to be added for review to ./auth/index.ts, for example, along with descriptions which will be used to generate the public API changes.

My understanding of the benefits of API extractor:

• Detects accidental changes to API.
• Generates markdown version of the API.

Is there anything else I am missing?

[hiranya911]

Yes, that's correct. The markdown report is just intended to make it easier for us to detect and review API changes in a single place.

Other features of API Extractor that we can possibly use in the future:

1. d.ts rollup: Allows combining multiple d.ts files into one.
2. API trimming: Allows marking APIs with @alpha, @beta, and @public annotations, and then we can configure which of those APIs should be included in the releases (e.g. we can cut a release that includes beta APIs for an EAP).
3. API doc generation: Generating markdown or DocFX documentation (this is in the roadmap for Firebase JS as well as other GCP Node.js projects)

[bojeil-google]

Sounds very promising. Thanks for the explanation.

[lahirumaramba]

This is great! Thanks!