crashlytics:symbols:upload: bundled Linux dump_syms.bin is glibc-linked, unusable on musl/Alpine — add a breakpad-binary override (or ship a static binary)

### Feature request

`crashlytics:symbols:upload` extracts and runs a bundled `dump_syms.bin` that is **dynamically linked against glibc** (ELF interpreter `/lib64/ld-linux-x86-64.so.2`). On a musl-based distro (Alpine Linux — extremely common for CI images) the binary cannot execute, so breakpad symbol generation fails. There is no CLI way to supply an alternative binary, and the alternative generator does not work for our case (see below), so the only way out is an out-of-band hack.

Please either:

1. **Add a CLI option (flag or env var) to override the breakpad/`dump_syms` binary** used by `crashlytics:symbols:upload` — parity with the Crashlytics **Gradle** plugin, which already accepts a `breakpadBinary` override. This requires no commitment to "support Alpine"; it just lets musl users point at a statically-linked `dump_syms` they provide. (preferred — smallest change)
2. Or **statically link (or ship a musl build of) the bundled Linux `dump_syms.bin`.**

### Environment

- `firebase-tools` 15.20.0 (installed via `npm i -g firebase-tools`)
- Alpine Linux (musl libc), x86_64, Docker CI image (Jenkins)
- Flutter Android app, uploading native (NDK) Crashlytics symbols

### What happens

`firebase crashlytics:symbols:upload --generator=breakpad --app=$APP_ID ./debug` extracts `.crashlytics/dump_syms.bin` and then fails trying to execute it, because that binary is a glibc-dynamic ELF:

```
$ file .crashlytics/dump_syms.bin
ELF 64-bit LSB ... dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux ...
```

Alpine has no `/lib64/ld-linux-x86-64.so.2` (musl), so the loader is missing and `dump_syms.bin` can't run → "Crashlytics found no symbols".

### Why the usual escapes don't work

- **`--generator=csym`** produces *empty* symbol files for Flutter's DWARF debug info ("Crashlytics found no symbols"). Only the breakpad generator (`dump_syms.bin`) parses Flutter's native symbols correctly, so csym is not a usable alternative for Flutter apps.
- **gcompat** (musl's glibc shim) owns `/lib64/ld-linux-x86-64.so.2` for NDK/ninja toolchain use, but it cannot actually *run* the glibc-linked `dump_syms.bin`.

### Current workaround (evidence this is purely a linking issue)

Install real glibc beside musl and repoint the interpreter, then re-run:

```sh
# 1st call extracts dump_syms.bin, then fails to run it under musl (output captured)
firebase crashlytics:symbols:upload --generator=breakpad --app=$APP_ID ./debug || true
patchelf --set-interpreter /usr/glibc-compat/lib/ld-linux-x86-64.so.2 .crashlytics/dump_syms.bin
firebase crashlytics:symbols:upload --generator=breakpad --app=$APP_ID ./debug # now succeeds
```

The real glibc comes from `sgerrand/alpine-pkg-glibc`, whose final release is `2.35-r1` (the project is dormant). So this workaround is fragile: an `--allow-untrusted` apk from an unmaintained project, pinned at glibc 2.35 forever — it will break the day `dump_syms.bin` is rebuilt against a newer glibc symbol, with no newer package available.

A CLI breakpad-binary override (option 1) would let us drop all of this and supply a statically-linked `dump_syms` instead.

### Steps to reproduce

1. Alpine x86_64 image with `firebase-tools` installed via npm.
2. Run `firebase crashlytics:symbols:upload --generator=breakpad --app= `.
3. Observe failure; inspect the extracted `.crashlytics/dump_syms.bin` with `file` → glibc-dynamic, interpreter `/lib64/ld-linux-x86-64.so.2`.