[6.2] Allow passing MutableSpan 'inout' without an experimental feature.

[atrick]

This adds a new lifetime inference rule, loosening the requirement for @Lifetime
annotations even when the experimental LifetimeDependence mode is
enabled. Additionally, it enables this new inference rule even when the
experimental mode is disabled. All other inference rules continue to require the
experimental feature. The rule is:

If a function or method has a single inout non-Escapable parameter other than
'self' and has no other non-Escapable parameters including 'self', then infer a
single @Lifetime(copy) dependency on the inout parameter from its own incoming
value.

This supports the common case in which the user of a non-Escapable type,
such as MutableSpan, wants to modify the span's contents without modifying
the span value itself. It should be possible to use MutableSpan this way
without requiring any knowledge of lifetime annotations. The tradeoff is
that it makes authoring non-Escapable types less safe. For example, a
MutableSpan method could update the underlying unsafe pointer and forget to
declare a dependence on the incoming pointer.

Disallowing other non-Escapable parameters rules out the easy mistake of
programmers attempting to trivially reassign the inout parameter. There's
is no way to rule out the possibility that they derive another
non-Escapable value from an Escapable parameteter. So users can still write
the following:

func reassign(s: inout MutableSpan<Int>, a: [Int]) {
  s = a.mutableSpan
}

The 'reassign' declaration will type check, but it's implementation will
diagnose a lifetime error on 's'.

Fixes rdar://150557314 ([nonescapable] Declaration of inout MutableSpan
parameter requires LifetimeDependence experimental feature)

(cherry picked from commit dbcba01)

main PR: #81656

--- CCC ---

Explanation: Enable limited lifetime inference when the experimental LifetimeDependence feature is disabled. This is necessary for MutableSpan usability. Otherwise, it is impossible to pass the mutable span into a function and mutate its elements!

Radar/SR Issue: rdar://150557314 ([nonescapable] Declaration of inout MutableSpan
parameter requires LifetimeDependence experimental feature)

main PR: #81656

Risks: (1) this runs a small amount of type checking code now by default that was previously guarded by a feature flag. This only affects usage od ~Escapable types. (2) this triggers the declaration checker in an arbitrarily different order which can slightly change the diagnostic output for invalid declarations.

Testing: I added unit tests for both pass and fail diagnostics both with and without the exerimental feature.

Reviewer: Doug Gregor

[atrick]

@swift-ci test

[atrick]

@swift-ci test

[atrick]

Windows: ModuleInterface/swift_build_sdk_interfaces/find-modules.test-sh' FAILED

[atrick]

@swift-ci test windows