[🚀 Feature]: [rust] Simplify Selenium Manager output to a single human/application toggle

### Description

Selenium Manager's `--output` flag has grown by accretion (`logger` → `json`/`shell` → `mixed`) into four modes that aren't four distinct use cases — they're two use cases with duplicates, and none of them provides the behavior conventionally expected of a CLI tool:

| `--output` | stdout | stderr | Notes |
|---|---|---|---|
| `logger` | • result + logs (text)
• Streamed | nothing | • Default |
| `shell` | • result + `INFO` logs (text)
• Streamed | • logged errors (text)
• Streamed | • Not currently used
• `WARN`/`DEBUG`/`TRACE` logging completely dropped, always (even with `--debug`) |
| `json` | • result + logs (JSON)
• Buffered | nothing | • java, py, rb, js (pending #13989)
• A crash can lose all logs
• `result.message` intended as the failure reason, but holds the last non-path `INFO`/`ERROR` log, even on success |
| `mixed` | • result (JSON)
• Buffered | • logs (text)
• Streamed | • .NET
• `error` field always holds the last non-path `INFO`/`ERROR` log, even on success |
| **Proposed CLI default** | • result (text)
• Buffered | • logs (text)
• Streamed | • Follows standard conventions |
| **Proposed Bindings default** | • result (JSON)
• Buffered | • logs (JSON)
• Streamed | • Follows standard conventions
• Error information not included in result but obtained from exit code |

I uncovered this issue trying to figure out how to emit a notice about what data is getting sent to Plausible. There is no way to do it that works properly in all the `--output` modes we support because it conflates concerns that should be independent.

### Proposal

Deprecate the `--output` toggle and replace with an **audience target toggle** — human vs application — with one consistent discipline underneath:

1. **Result → stdout, all diagnostics → stderr**, always. Not a per-mode choice.
2. **One toggle selects only the payload shape on stdout**: human-readable text (default) vs structured (JSON). (`logger`/`shell` collapse into human; `json`/`mixed` collapse into application.)
3. **Model the result as data**, not a constant-prefixed log line — emit `driver_path`/`browser_path` directly.
4. **Failure is the exit code** — the reason is logged to stderr (shown to a CLI user, replayed by a binding), never scraped into the result payload.
5. Application mode streams logs on stderr, leaving stdout as the clean result document — and those streamed logs should be **structured** (one JSON object per line, e.g. `{"level","timestamp","message"}`) so bindings can replay them without each writing a text parser.

**Relevant context / related issues**

- **#13989 — "Leverage streaming output in the bindings"** (open): the consumer-side tracker. This issue is the **producer/contract** it depends on; #13989 keeps its per-binding checklist (Ruby/Python/Java/JS pending) and should be updated to consume the new contract rather than today's `mixed`.

### Have you considered any alternatives or workarounds?

**Fix the current `--output` modes in place** rather than adding a new flag. Rejected because `--output json`/`mixed` are a consumed contract — Java/Python/Ruby/JS/.NET parse their exact shape — so changing their behavior in place breaks every binding at once. A new flag lets `--output` keep working through a deprecation window while bindings migrate deliberately. (Selenium Manager is in beta, so flags may change without guarantee, but a deprecation notice on `--output` still makes the migration explicit rather than silent.)

Start with Selenium Manager’s --output handling and the binding consumers referenced in #13989; compare the current logger, shell, json, and mixed contracts with the proposed human/application split. Done means the new contract sends results to stdout, diagnostics to stderr, uses structured application logs, and provides a migration path while the existing flag is deprecated.

Written by the indexing model from the issue text.