[6.3][rbi] Mark mutable weak capture boxes containing Sendable types as immutable if they are never interprocedurally written to and teach SILIsolationInfo::isSendable that they are meant to be treated as Sendable.

[gottesmm]

Explanation: This fix resolves a regression introduced in #82427 where weak
self-captures in closures began triggering concurrency errors.

The problem occurs because:

1. Weak captures are stored in heap-allocated boxes.
2. By default, these boxes are mutable (var) even when they're never modified after initialization
3. Mutable boxes are non-Sendable (they could be unsafely mutated from multiple threads)
4. Region isolation now correctly errors when sending non-Sendable values across isolation boundaries

This breaks a pattern widely used in Swift code:

@MainActor class C {
    func test() {
        timer { [weak self] in  // Captures self in a mutable box
            Task { @MainActor in
                self?.update()  // ERROR: sending mutable box risks data races
            }
        }
    }
}

Note how even though self is Sendable since it is MainActor-isolated, the box
containing the weak reference is not Sendable because it is mutable.

To fix this, I added a new pass that recognizes such boxes as actually being
immutable and updated the SILIsolationInfo infrastructure to use that
information.

In more detail: The pass works by:

• Walking the module looking for alloc_box that are used for mutable weak var
  closure captures.

• The uses of such boxes are analyzed recursively and interprocedurally to prove
  that the box is never written to beyond an initial initialization store.

• If we prove that there are no such writes, we mark the box and all function
  arguments associated with any closures we visited as immutable.

Scope: Narrowly targeted to weak variable captures only. The pass uses
conservative pattern matching specific to this use case, minimizing impact on
other compiler functionality.

Issues: rdar://166081666

Original PRs: #86312

Risk:

• Compiler Crash: Medium. I think this is reasonable since any introduction of a
  new compiler pass contains some risk. But this is mitigated by the
  conservativeness and simplicity of the pass. As an example: we do not
  introduce any new dataflow, any new data structures, and instead just use a
  standard DenseSet and a recursive dataflow walk.

• Semantic Risks: Low. We could introduce new holes in the concurrency model by
  considering safe mutable weak vars that are written to. This is mitigated by
  the pass using a pattern match allow list. All patterns that do not match this
  allow list are assumed unsafe, so we should fail to pattern match anything
  else and just get the current behavior.

Testing: Swift -verify tests and SIL FileCheck tests
Reviewers: @rjmccall

[gottesmm]

@swift-ci test

[gottesmm]

I think 1-2 tests may fail due to differences on this branch related to diagnostics. I am building locally now in case this happens. But no reason not to start the testing in case I am wrong.

[gottesmm]

Original PR: #86312

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

Test failed due to a cherry-picking error. I put in a parser test from main that wasn't on 6.3... :sigh:

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test windows platform

[gottesmm]

@swift-ci test windows platform