[red-knot] Properly model control flow through finally suites

[AlexWaygood]

finally suites in try/except blocks have very complex control flow, which we don't yet model, and need to.

I've already written extensively about the complexities of finally blocks, so I won't try to summarise them again here. Instead, I'll point to:

• This TODO comment here:

  ruff/crates/red_knot_python_semantic/src/semantic_index/builder.rs

  Lines 929 to 939 in 76e4277

  	// TODO: there's lots of complexity here that isn't yet handled by our model.
  	// In order to accurately model the semantics of `finally` suites, we in fact need to visit
  	// the suite twice: once under the (current) assumption that either the `try + else` suite
  	// ran to completion or exactly one `except` branch ran to completion, and then again under
  	// the assumption that potentially none of the branches ran to completion and we in fact
  	// jumped from a `try`, `else` or `except` branch straight into the `finally` branch.
  	// This requires rethinking some fundamental assumptions semantic indexing makes.
  	// For more details, see:
  	// - https://astral-sh.notion.site/Exception-handler-control-flow-11348797e1ca80bb8ce1e9aedbbe439d
  	// - https://github.com/astral-sh/ruff/pull/13633#discussion_r1788626702
  	self.visit_body(finalbody);

• The various finally-related TODO comments in our exception-handler control-flow test suite, from this point onwards: https://github.com/astral-sh/ruff/blob/main/crates/red_knot_python_semantic/resources/mdtest/exception/control_flow.md#exception-handlers-with-finally-branches-but-no-except-branches
• The full writeup of exception-handler control flow I put together here: https://astral-sh.notion.site/Exception-handler-control-flow-11348797e1ca80bb8ce1e9aedbbe439d