We had a number of problems either "only in" or "only without" library
evolution and protocols, so in order to increase the test coverage, run
a few of the crucial tests in both modes.
This actually manifested as an pointer auth crash, but the real reason
being is that we messed up the order of elements in the witness table.
If we'd skip the accessor like this, the types we sign/auth with would
no longer align and manifest in a crash.
There is no real reason to skip this entry so we just bring it back, and
avoid making this special in any way.
This unlocks a few tests as well as corrects any distributed+protocol
use where a requirement distributed var was _followed by_ other
requirements.
resolves rdar://125628060
This is a crucial fix without which we can crash on some distributed
protocol declarations with @Resolvable. We cannot "just" use a String to
represent the "fake base" of the thunks, and must instead find the
$Target macro generated type and use it as the base of the thunk's
mangling.
Calls are made in such way that record for the protocol requirement:
`$s4main28GreeterDefinedSystemProtocolP5greetSSyYaKFTEHF` points at
`$$s4main29$GreeterDefinedSystemProtocolC5greetSSyYaKFTE` which makes a
dispatch through the _apropriate_ witness table.
And the record for the $witness named e.g.
`$s4main29$GreeterDefinedSystemProtocolC5greetSSyYaKFTEHF` points to
`$s4main28GreeterDefinedSystemProtocolPAA11Distributed01_F9ActorStubRzrlE5greetSSyYaKFTE`
which is an extension method: `distributed thunk (extension in main):main.GreeterDefinedSystemProtocol< where A: Distributed._DistributedActorStub>.greet() async throws -> Swift.String`,
this very specific design allows us to call the "right method" on the
recieving end of a remote call where we do not know the recipient type.
