[6.0][Concurrency] Check varIsSafeAcrossActors in getActorIsolationForReference.

[hborla]

• Explanation: A recent change to add a default implementation of mutating func next() on AsyncIteratorProtocol caused code like the following to fail to type check:

  @available(SwiftStdlib 5.1, *)
  actor Iterator: AsyncIteratorProtocol {
    init() {}
    func next() throws -> Int? { nil }
  }
  
  @available(SwiftStdlib 5.1, *)
  actor SafeMutatingCall {
    private let iterator: Iterator
  
    public init() async throws {
      self.iterator = Iterator()
      _ = try await self.iterator.next() // error: cannot call mutating async function 'next()' on actor-isolated property 'iterator'
    }
  }

  This happened because now overload resolution selects the mutating default implementation from AsyncIteratorProtocol, and the actor isolation checker code that diagnoses mutating/inout calls on isolated properties did not consider whether a property is safe to access across actors. This change only treats nonisolated let properties in actors as isolated if access is from outside the module or the property type is not Sendable, following the rules in [Concurrency] nonisolated can only be applied to actor properties with Sendable type. #70909.

• Scope: Only impacts actor isolated properties that are let constants whose type is Sendable.

• Risk: Low; treating Sendable actor isolated let properties as nonisolated within the module allows more code to compile.

• Testing: Updated existing expected diagnostics, and added a new test case for the source compatibility issue.

• Reviewer: @DougGregor

• Main branch PR: [Concurrency] Check varIsSafeAcrossActors in getActorIsolationForReference. #73279

[hborla]

@swift-ci please test