feat(remote_config): add Firebase Remote Config support

[long1eu]

Summary

Adds Firebase Remote Config support to the Dart Admin SDK: template management (read, validate, publish with force, rollback, list versions, parse from JSON) and server-side template evaluation (fetch + in-process rules engine for percent rollouts and string/numeric/semver custom signals).

Notable design choices

• Direct REST calls instead of googleapis-generated client — the generated client doesn't expose response headers (no ETag) and doesn't accept If-Match, both of which are required for optimistic concurrency and force-publish.
• Server-template publishing is not exposed — the REST API doesn't accept writes on the firebase-server namespace; server templates are Console-managed only.
• Field shapes and required/output-only annotations match the v1 discovery schema.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[long1eu]

@kevmoon @Lyokone can you have a look? :D

[demolaf]

Hi @long1eu , thanks for the PR!

At the moment there's no support for Remote Config in the googleapis generated package and all our Firebase services are routed through it.

I'll get some more details on what the plan is there and keep this PR up to date.

[long1eu]

Thanks for taking a look @demolaf!

Quick context that might be useful while you check on the googleapis plan:

• firebaseremoteconfig was in package:googleapis up through 13.2.0; it was dropped between 13.2.0 and 14.0.0 and isn't in 16.0.0 (the version this repo currently depends on). So even if I had wanted to route through it, the generated client isn't shipped today.

• More importantly, four of the five admin endpoints (getTemplate, publishTemplate, validateTemplate, rollback) require reading and setting the ETag / If-Match headers — that's how Remote Config does optimistic concurrency, and how force=true is expressed (If-Match: *). The googleapis-generated clients don't surface request/response headers, so even when firebaseremoteconfig was available in googleapis, those four endpoints would still need a raw-REST path. Only listVersions is a clean GET that could go through the generated client.

Happy to take this in any direction that fits the project's plans:

1. Leave as-is — raw REST throughout, consistent within the new remote_config library.
2. Hybrid — route listVersions through googleapis if/when firebaseremoteconfig is re-added; keep raw REST for the four ETag-bound endpoints.
3. Wait for the broader googleapis-package decision before merging, and refactor accordingly.

Just let me know which you'd prefer once you have more details on the plan.