Fix FURB108 false positive when operands depend on short-circuit evaluation

[worksbyfriday]

Summary

Fixes #350.

When comparing values with or, the right-hand operand may depend on short-circuit evaluation for safety. For example:

cutoff = bisect(events, threshold)
if cutoff == 0 or events[cutoff - 1] == 0:
    pass

FURB108 previously suggested 0 in (cutoff, events[cutoff - 1]), which eagerly evaluates both operands and can raise IndexError when cutoff == 0.

This PR skips the FURB108 suggestion when non-common operands contain subscript expressions (IndexExpr) or function calls (CallExpr), as these may raise exceptions or have side effects when eagerly evaluated. Simple comparisons like x == "abc" or x == "def" continue to be flagged normally.

This aligns with the "only allow basic comparisons" approach from the maintainer's comment on #350, as a conservative first step toward better safe/unsafe detection.

Test plan

• Added test cases to test/data/err_108.py for subscript and call operands
• Verified original bug report case (cutoff == 0 or events[cutoff - 1] == 0) no longer triggers
• Verified simple comparisons still trigger as expected
• All pre-existing tests pass (only pre-existing err_175 failure unrelated to this change)

[worksbyfriday]

Superseded by #369 which uses a cleaner approach: positive allowlist of safe expression types (_is_simple_expr) rather than a visitor-based blocklist, and reuses get_common_expr_positions from common.py instead of manually re-implementing common-operand detection.