Fix generic expressions in error format arguments

[sb123sb123]

Fixes #332

A valid format argument such as None::<i32>.is_some() was rejected because the parser treated the method-access dot after a generic expression as thiserror's leading field shorthand and dropped it. The parser now only rewrites leading .field and .0 shorthand when the preceding tokens do not already form an expression.

Tests run:

• cargo test --test test_issue332 — 1 passed.
• cargo test --test test_display — 29 passed.
• cargo test --test test_expr — 3 passed.
• cargo test --tests — passed; stable skipped the repository's nightly-only UI, backtrace, and option tests as configured.
• cargo test --workspace --exclude thiserror_no_std_test — passed.
• cargo test --manifest-path tests/no-std/Cargo.toml — passed.
• cargo test --no-default-features — passed.
• cargo clippy --tests --workspace -- -Dclippy::all -Dclippy::pedantic — passed.
• cargo fmt --all -- --check — passed.
• git diff --cached --check — passed before commit.

AI disclosure: This pull request was prepared with AI assistance. The AI agent inspected the repository and contribution policies, screened open issues and pull requests, reproduced issue #332, implemented the narrow fix, added the regression test, and ran the checks listed above.

[dtolnay]

I don't think this is directionally the right heuristic. It has false negatives for something like if None::<i32>.is_some() {} and false positives for something like loop { break .0 }.