feat: accept Expression for v2 RTDB instance option

[IzaakGough]

Fixes #1613

Summary

Allow the v2 Realtime Database trigger instance option to accept a deploy-time param (Expression<string>), not just a plain string.
This lets functions target different RTDB instances per environment without triggering the deployment-time .value() warning.

Problem

ReferenceOptions.instance was typed and handled as a plain string.

Passing defineString('REALTIME_INSTANCE') for instance either failed type-checking or caused the SDK to eagerly resolve the param during deploy, which emitted the standard .value() deployment warning.

Solution

• Widen ReferenceOptions.instance to string | Expression<string>.
• Preserve expression-backed instances through endpoint generation instead of resolving them in getOpts().
• Serialize expression-backed instances into the manifest as CEL expressions.
• Resolve the expression only at runtime when the trigger needs to construct its path pattern and event params.

Testing

• Added unit coverage for getOpts() preserving an Expression<string>.
• Added endpoint/manifest coverage for expression-backed instance values.
• Added a test that verifies no deployment-time warning is emitted when defining the trigger with a param-backed instance.
• Added a runtime test confirming instance resolution and param extraction still work.

[gemini-code-assist]

Code Review

This pull request enhances Realtime Database (RTDB) ReferenceOptions to allow Expression<string> for the instance property, enabling dynamic resolution of instance names. The getOpts utility function has been updated to process these expressions, and a new test case validates this functionality. The review suggests improving the new test case by replacing magic strings with named constants for better readability and maintainability.

[CorieW]

lgtm

[cabljac]

some duplication here, can we clean up

[cabljac]

is this casting necessary - can we double check