LockIsolated.withValue closure should be sendable

[stephencelis]

Brought up by @kabiroberai in Slack with this demo of the issue:

class Bad {
  var i = 0
  func racy() { i += 1 }
}

let bad = LockIsolated(Bad())

var _bad: Bad?
bad.withValue { _bad = $0 }
_bad?.racy()  // not lock-isolated!

[stephencelis]

This line (and the hashable line) do emit warnings in strict concurrency, so we should have a timetable for removal or consider making them unavailable, though that is a breaking change.

[kabiroberai]

Are there new Sendability issues if you continue using withValue here?

Worth mentioning that OSAllocatedUnfairLock has a similar API where withLock takes a Sendable closure but there's also a withLockUnchecked that doesn't enforce Sendability. Would be cleaner ergonomically than requiring the use of UncheckedSendable, and you could use the unchecked variant here and in the Hashable impl (assuming you want to keep the conformances.)

[stephencelis]

@kabiroberai Yup, now that withValue is sendable we can't traffic the lhsValue into the closure unless it's sendable.

withLockUnchecked is an interesting idea, though I still think equatability and hashability should probably be on the chopping block since they are simple operations that should not block/lock.