[5.9][move-only] A series of batched commits.

[gottesmm]

This PR contains a few batched changes for 5.9. There is at least one change
that just updates tests and another that eliminates a dead field. I didn't create CCC for them.
Here are the CCC for the major changes:

Commit f634acf

• Description: [move-only] Fix a thinko where we are treating inout convention
as a consuming use instead of liveness use. The effect of this change is that
when we were capturing an inout in a closure, we were treating it as if it was
consuming it causing us to give the wrong diagnostic.
• Risk: Low risk. Only affects noncopyable types.
• Original PR: #65864
• Reviewed By: @jckarter
• Testing: I added tests/updated other tests to make sure this did not happen.
• Resolves: rdar://109217216

Commit a10a5db

• Description: [move-only] Ensure that resilient deinits take their self
argument as an address argument instead of an object. The function signature
was already correct, just the logic in SILGen around cerating the SIL argument
assumed that we would always have an object since it was setup originally just
to support classes which even when resilient are still objects.
• Risk: Low risk. Only affects noncopyable types.
• Original PR: #65842
• Reviewed By: @jckarter
• Testing: I added tests/updated other tests to make sure this did not happen.
• Resolves: rdar://109170069

Commit a10a5db

• Description: [move-only] Teach the move only object checker how to handle
concrete resilient guaranteed arguments.

The only difference from normal concrete guaranteed parameter emission is we
have a load_borrow on the argument before the copy_value. That is instead of:

bb0(%0 : @guaranteed $Type):
  %1 = copy_value %0
  %2 = mark_must_check [no_consume_or_assign] %1

we have,

bb0(%0 : $*Type): // in_guaranteed
  %1 = load_borrow %0
  %2 = copy_value %1
  %3 = mark_must_check [no_consume_or_assign] %2

So I just needed to update the checker to recognize that pattern.

This is tested by just making sure that the checker can handle the borrowVal in
the tests without emitting an error.

• Risk: Low risk. Only affects noncopyable types.
• Original PR: #65842
• Reviewed By: @jckarter
• Testing: I added tests/updated other tests to make sure this did not happen.
• Resolves: rdar://109170906

Commit 43fb28f && dddafe8

• Description: [move-only] Spill noncopyable types that are objects using
store_borrow if we call a resilient function that takes it in_guaranteed.

This is a typical update needed around library-evolution. Since we are inside
the module itself, the value is concrete and thus an object, but the API it
uses is resilient, so we have to pass it as an address.

The second commit is just a small update to the first that fixes an issue
where we were not properly handling opaque values with this code path. I just
didn't squash the two commits.

• Risk: Low risk. Only affects noncopyable types.
• Original PR: #65842
• Reviewed By: @jckarter
• Testing: I added tests/updated other tests to make sure this did not happen.
• Resolves: rdar://109171001

Commit d2b7e70
Commit cd3734c
Commit de5737d
Commit a6edf15
Commit 052ecd1

• Description: Originally, we were going to follow the AST in a strict way in
terms of what closures are considered escaping or not from a diagnostics
perspective. Upon further investigation I found that we actually do something
different for inout escaping semantics and by treating the AST as the one
point of truth, we are being inconsistent with the rest of the compiler. As an
example, the following code is considered by the compiler to not be an invalid
escaping use of an inout implying that we do not consider the closure to be
escaping:

func f(_ x: inout Int) {
  let g = {
    _ = x
  }
}

in contrast, a var is always considered to be an escape:

func f(_ x: inout Int) {
  var g = {
    _ = x
  }
}

test2.swift:3:13: error: escaping closure captures 'inout' parameter 'x'
    var g = {
            ^
test2.swift:2:10: note: parameter 'x' is declared 'inout'
func f(_ x: inout Int) {
         ^
test2.swift:4:11: note: captured here
        _ = x
          ^

Of course, if we store the let into memory, we get the error one would expect:

var global: () -> () = {}
func f(_ x: inout Int) {
  let g = {
    _ = x
  }
  global = g
}

test2.swift:4:11: error: escaping closure captures 'inout' parameter 'x'
  let g = {
          ^
test2.swift:3:10: note: parameter 'x' is declared 'inout'
func f(_ x: inout Int) {
         ^
test2.swift:5:7: note: captured here
    _ = x
      ^

By reverting to the old behavior where allocbox to stack ran early,
noncopyable types now have the same sort of semantics: let closures that
capture a noncopyable type that do not on the face of it escape are considered
non-escaping, while if the closure is ever stored into memory (e.x.: store
into a global, into a local var) or escapes, we get the appropriate escaping
diagnostics. E.x.:

public struct E : ~Copyable {}
public func borrowVal(_ e: borrowing E) {}
public func consumeVal(_ e: consuming E) {}

func f1() {
  var e = E()

  // Mutable borrowing use of e. We can consume e as long as we reinit at end
  // of function. We don't here, so we get an error.
  let c1: () -> () = {
    borrowVal(e)
    consumeVal(e)
  }

  // Mutable borrowing use of e. We can consume e as long as we reinit at end
  // of function. We do do that here, so no error.
  let c2: () -> () = {
    borrowVal(e)
    consumeVal(e)
    e = E()
  }
}

Additionally, I did follow on work to ensure that:

1. In these cases we treat applications of the partial_apply or passing the
   partial_apply off to a function as the liveness requiring uses rather than the
   partial_apply formation and the end lifetime of the partial_apply.

2. When we do have an escaping partial_apply where we emit an inout capture
   error (and thus bail out of move checking early), we no longer attempt to emit
   "copy of noncopyable type" errors.

• Risk: Low risk. Only affects noncopyable types.
• Original PR: #65911
• Reviewed By: @jckarter
• Testing: I added tests/updated other tests to make sure this did not happen.
• Resolves: rdar://109426644

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

NOTE: This isn't actually a bug. I just by mistake left this in this specific commit. I filled in the if statement body here: de5737d#diff-9c8ec5474745801be2148dbcd9e1178e6aaead4739668d88d551b4137047cb8b

[gottesmm]

Specifically in 052ecd1