Fix quadratic escaped string parsing in escaped_byte_buf

[enomado]

Fixes #609.

escaped_byte_buf calls find('"') once per escape. That call scans from the cursor to
the closing quote, while the cursor only advances past one escape per iteration —
so a string with N escapes rescans the tail N times, making string parsing O(N²) in the
number of escapes.

Unlike #607, this is not limited to ron::Value / deserialize_any: it affects any
deserialization of a string containing escapes, including the typed path.

Root cause

The quadratic scan came in with #534, which replaced a single scan for the first of
" / \\:

let (new_i, end_or_escape) = self
    .find_char_index(|c| matches!(c, '\\' | '"'))
    .ok_or(Error::ExpectedStringEnd)?;

with "find the closing quote, then look for a backslash before it". That is genuinely
faster for the common no-escape case, so this PR keeps it as the fast path outside
the loop. Inside the loop, though, only the first of " / \\ is ever needed — scanning
just to the nearest delimiter is both sufficient and linear.

Affected releases (git tag --contains 08c691d0): v0.9.0 … v0.12.2.

Result

["\n\n\n…"], release build, at d0e99bc:

input	before	after	ratio before	ratio after
25 KB	6.64 ms	0.10 ms	—	—
50 KB	26.24 ms	0.19 ms	x3.95	x1.94
100 KB	103.38 ms	0.38 ms	x3.94	x1.97
200 KB	414.43 ms	0.76 ms	x4.01	x2.00
400 KB	1652.96 ms	1.54 ms	x3.99	x2.02

1073x at 400 KB, and the per-doubling ratio goes from ~4 (quadratic) back to ~2
(linear). Throughput: 0.2 MB/s → 260 MB/s.

Both branches already did the same extend_from_slice, so the fix also makes the loop
slightly shorter.

Tests

The regression test asserts on scaling, not absolute time, so it stays meaningful on
slow or noisy CI: the ratio is ~2 when linear and ~4 when quadratic, and the threshold
(3.0) sits far from both. It fails on the pre-fix parser (measured ratio 3.96) and passes
after. Same shape as the test in #608.

The existing suite (453 tests) stays green, plus the 2 new ones.

Note on error reporting for invalid input

For an unterminated string whose invalid escape follows an escaped quote — e.g.
"a\"b\c — this now reports InvalidEscape instead of ExpectedStringEnd. That is what
the parser did before #534 (verified by running the pre-#534 tree), and it is arguably the
more accurate diagnostic, since there genuinely is an invalid escape.

The outer find('"') is deliberately left untouched, so the common case — an unterminated
string with no escapes, e.g. the (4, "Hello) case pinned in de::tests::forgot_apostrophes
— still reports ExpectedStringEnd exactly as today. No existing test changes behaviour.

Happy to preserve the current error exactly if you'd prefer; it costs a little extra state
to track the last found quote across iterations.

[enomado]

Fixed the CI: dropped the black_box hint (only stable since Rust 1.66, so it broke the 1.64 MSRV job with E0658) and split the long find(['"', '\\']) line to satisfy rustfmt. All green now.