Follow-up tasks for `redundant-condition(-strict)` rules

[AlexWaygood]

1. Mypy's truthy-function rule also triggers for Callable annotations; ours does not, currently, because we model non-function-like Callables as having ambiguous truthiness (Multiplay gist: d120c34286b5c1b438f128e33cdbc789). We could experiment with having a third rule that triggers on Callable-annotated variables that are used in boolean contexts. Similarly, mypy's truthy-iterable error code flags arbitrary Iterable[]- and Iterator[]-typed variables used in boolean contexts. We currently only flag generators, since Iterable and Iterator have ambiguous truthiness.

   • [ty] Add a rule that detects suspicious uses of Callable, Iterable, Iterator or Generator types in a boolean context ruff#28554

2. Similarly, mypy's redundant-expr diagnostic triggers on code such as this (multiplay gist: bdd9ec316ce12e024e6be186392bd703), which is not flagged by any ty rule currently:

   def normalize(s: str):
      return s is not None and s

   It would be good to look into exactly what heuristics mypy is using to flag that without having too many false-positive errors. We left all and and or expressions out of the initial implementation when they occurred outside boolean tests; it felt too complex to get this right without too many false positives. Perhaps we could flag these as part of redundant-condition(-strict), or perhaps we could have a separate rule for cases like this.

3. The rules currently err on the side of caution by assuming that this assert is meant to mark the branch as "deliberately unreachable", because the assert could evaluate to False:

   def f(x: int, y: bool):
       if not isinstance(x, int):
           assert y

   That probably leads to us having false negatives in some situations; it would be good to experiment with this and see if refining the heuristic to only count assert statements that are definitely False actually leads to an increase in false positives or not

4. Add subdiagnostics highlighting the reachability impliciations of a test being either always-truthy or always-falsy.

   • [ty] Add subdiagnostics to redundant-condition rules warning about reachability implications ruff#28263
   • [ty] [redundant-condition rules] Extend unreachable-code annotations to while, assert and match statements ruff#28290
   • [ty] Annotate unreachable code caused by boolean operands ruff#28521

5. Currently we only flag assert statements if the type of the test being asserted is not assignable to bool or int. But perhaps we could also detect cases like this, where it appears that the suite below the assert is intended to be reachable, but we infer the assert as always failing due to the condition always being falsy:

   assert 1 == 2
   print('this looks like it was meant to be reachable')

   [ty] Diagnose failing assertions followed by nontrivial statements ruff#28357

6. Currently we assume that any condition that is an AST-literal True, False, 1 or 0 is deliberate. But maybe we should flag something like this, on the grounds that it clearly looks like the suite after the while is meant to be reachable?

   while True:
       pass
   print('this looks like it was meant to be reachable')

7. Suppress diagnostics on Call expressions that return None, when they occur inside and, or or not expressions? These often have side effects.

   • [ty] Exempt calls returning None in standalone boolean expressions ruff#28355

8. Move "short-circuit" conditions from redundant-condition-strict to redundant-condition?

   • [ty] Remove the short-circuit exemption from redundant-condition ruff#28356