[refurb] Mark fixes that remove unknown separators as unsafe (FURB105)

[jesco-absolut]

Summary

Fixes #20919.

The main learning point after working on this was, that python validates sep even when it is unused;
removing an unknown value can suppress a TypeError; therefore only known-valid separators receive a safe fix.

FURB105 can suggest removing an unused sep argument from a print call. The fix was previously considered safe unless
evaluating the separator had observable side effects.

Python still validates sep even when the call only prints one value. If the separator is neither None nor a string,
the original call raises a TypeError. Removing an unknown separator can therefore change the program's behavior even
when evaluating its expression has no side effects.

This change makes the fix conservative: removing sep is considered safe when its value is statically known to be a
string literal or None. Other separator expressions retain the FURB105 diagnostic, but their fix is marked unsafe.

The fixtures cover both a known-valid None separator and a separator supplied through an unknown variable. The rule
documentation and snapshots are updated to reflect the safety distinction.

Test Plan

• Ran the focused FURB105 fixture and snapshot test:
  cargo test -p ruff_linter --lib rule_printemptystring_path_new_furb105_py_expects
• Ran cargo fmt --all --check

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[ntBre]

Thanks! I was initially worried that this is quite a restrictive check, but I think trying to make it more permissive isn't worth the complexity it would introduce. For example, we could try to use our typing module to make cases like this safe:

def p(sep: str): print(1, sep=sep)
def p(sep: None): print(1, sep=sep)
def p(sep: str | None): print(1, sep=sep)

but then we'd need separate handling for a case like:

def foo():
    sep = ""
    print(1, sep=sep)

and other cases. Given that literals are probably the most common case and that this doesn't show any negative ecosystem impact, I think this is an acceptable tradeoff.

We can try to expand the check again when we get access to ty's type inference.