Instead, use the `%target-swift-5.1-abi-triple` substitution to compile the tests
for deployment to the minimum OS versions required for use of _Concurrency APIs.
When determining whether a non-sendable type is a nominal type that is
affected by `@preconcurrency`, be sure to look at the specific type
even when it's part of larger type, e.g., the `NS` in `NS?`. This
makes `@preconcurrency` work properly through structural types like
arrays, optionals, and dictionaries.
While here, also check whether the nominal declaration itself has been
marked as `@preconcurrency`.
Fixes rdar://125081249.
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
This translates the rules for @preconcurrency import from SE-0337 into the
region isolation world. Specifically if a module is compiled without strict
concurrency checking and imported with @preconcurrency:
1. All types from that module that are implicitly non-Sendable have diagnostics
suppressed in swift 5 and swift 6.
2. All types from that module that are explicitly non-Sendable emit warnings in
both swift 5 and swift 6.
rdar://126804052
