Just don't store the begin instruction.
This led to problem if the "begin" was not actually an instruction but a block argument.
Using the first instruction of that block is not correct in case the range ends immediately at the first instruction, e.g.
```
bb0(%0 : @owned $C):
destroy_value %0
```
When visiting consumes, also visit `extend_lifetime` instructions.
These instructions are not lifetime ending, but together with the
consumes, they enclose the users of a value.
Add a flag to LinearLiveness to control whether these instructions are
added so that the verifier can use verify that all such instructions
appear outside the linear lifetime boundary (not including them).
Compute, update and handle borrowed-from instruction in various utilities and passes.
Also, used borrowed-from to simplify `gatherBorrowIntroducers` and `gatherEnclosingValues`.
Replace those utilities by `Value.getBorrowIntroducers` and `Value.getEnclosingValues`, which return a lazily computed Sequence of borrowed/enclosing values.
Add PartialApplyInst.hasNoescapeCapture
Add PartialApplyInst.mayEscape
Refactor DiagnoseInvalidEscapingCaptures. This may change functionality because tuples containing a noescape closure are now correctly recognized. Although I'm not sure such tupes can ever be captured directly.
This is what you need to correctly analyze OSSA.
- computeLinearLiveness
- computeInteriorLiveness
- InteriorUseVisitor
- OwnershipUseVisitor
- LivenessBoundary
Along with BorrowUtils.swift, all of our OSSA transformations are
built on top of these fundamentals. With these APIs, we can build
anything OSSA-related in SwiftCompilerSources. These utilities are
immediately needed for borrowed arguments and lifetime dependence. In
the near future, we can also use them to complete OSSA lifetimes and
*correctly* fixup OSSA after transformation without introducing lots
of copies and creating lots of incorrect corner cases.
