feat(core): Error Handling Revamp

[jonathanedey]

This PR makes changes the usage of firebase errors and includes the following changes:

• Exposes all service-specific error classes, error code types and base FirebaseError class.
• Exposes the associated error codes types for those errors.
• Exposes ErrorInfo and HttpResponse classes for better error handing.
• Adds 2 new fields to ErrorInfo FirebaseErrors: cause and HttpResponse.
• Converts AuthClientErrorCode, MessagingClientErrorCode, InstallationsClientErrorCode, InstanceIdClientErrorCode from classes to constants.

[gemini-code-assist]

Code Review

This pull request refactors the error handling across the Firebase Admin SDK by introducing a structured ErrorInfo interface and updating various error classes to accept this object. This allows for better inclusion of httpResponse and cause (underlying error) information, improving debuggability. I have provided feedback regarding missing semicolons in auth-api-request.ts and suggested simplifying error messages by removing redundant low-level error details, as these are now captured by the cause property.

[lahirumaramba]

LGTM! Thanks! (added couple comments)

[lahirumaramba]

Is this something we can address (for both PrefixedFirebaseError and ErrorInfo? I think it is okay to ignore this but I am just double checking :)

[jonathanedey]

For ErrorInfo it's the same scenario we have for App. Where even though we export it commonly, api documenter wants it to be exported again from other paths where it is used in the definition. So i don't think we have good options other than exposing it from multiple paths.

For PrefixedFirebaseError this is technically internal logic and not exposed at all even though it's a middle step between FirebaseError and the service specific errors. Not sure if there is a way to exclude it from the docs.