6.2: [CoroutineAccessors] Use async bit in descriptors.

[nate-chandler]

Explanation: Enable back deployment of coroutine accessors on platforms with ptrauth (without requiring a back deployment library).

Method descriptors and protocol requirement descriptors specify characteristics of class and protocol members. They are used at runtime to instantiate class vtables and protocol wtables. On platforms with ptrauth, their flags specify whether the members should be copied into vtable/wtable as code or data. In the case of protocols, how this copying should be done is determined by a switch over the kind. Already deployed runtimes can't know about new kinds.

Previously, new kinds had been added for the new accessor kinds. In order for back-deploying binaries--i.e. those built to be run in contexts featuring already deployed runtimes--to use new kinds, they would need a back deployment runtime. Otherwise, that already deployed runtime's implementation of copying witness implementations in vtables which relies on a switch over the kind would fall through the switch and hit a fatal error.

Here, instead of adding a back deployment library, those new kinds are removed. Because these new coroutines are referred to via "coroutine function pointers" (much like how async functions are referred to via async function pointers) which are global structs containing a relative pointer to the function and a frame size, they use data ptrauth key (asda) rather than the code key (asia). Runtimes already deployed and forthcoming all use this key to sign async function pointers: in particular, they check whether the MethodDescriptorFlags/ProtocolDescriptorFlags have the async bit set.

Cause all runtimes to use the appropriate key for coroutine function pointers by reusing the old preexisting (i.e. "old ABI") coroutine accesor kinds on the flags and setting the async bit. This also eliminates the problem of falling through the switch on already deployed runtimes because no new kinds are added.

Doing this doesn't collide with any other meaning of the flags because the combination of Kind=Read/Modify and IsAsync=true is not used on any deployed or forthcoming runtimes. Here, that combination is reserved to indicate "new ABI read/modify coroutine accessor". If in the future async read/modify accessors were to be added to the language, they would use the new ABI and consequently still not use the Kind=Read/Modify and IsAsync=true pairing, even if the old kinds were kept on the flags. So if such a feature were to be added in the future, either (1) a back deployment library containing new kinds might at that point need to be added (worst case) or (2) it might again be sufficient to use this pairing (Kind=Read/Modify and IsAsync=true) to indicate that the member is referenced via data rather than code (best case).
Scope: Affects the experimental CoroutineAccessors feature.
Issue: rdar://148628149
Original PR: #80520
Risk: Low, removes newly-added cases from the runtime, only affects the coroutine accessors feature.
Testing: CI.
Reviewer: Arnold Schwaighofer ( @aschwaighofer )

[nate-chandler]

@swift-ci please test