[AutoDiff] Support custom derivatives for @_alwaysEmitIntoClient functions

[kovdan01]

Consider an @_alwaysEmitIntoClient function and a custom derivative defined
for it. Previously, such a combination resulted different errors under different
circumstances.

Sometimes, there were linker errors due to missing derivative function symbol -
these occurred when we tried to find the derivative in a module, while it
should have been emitted into client's code (and it did not happen).

Sometimes, there were SIL verification failures like this:

SIL verification failed: internal/private function cannot be serialized or serializable: !F->isAnySerialized() || embedded

Linkage and serialization options for the derivative were not handled properly,
and, instead of PublicNonABI linkage, we had Private one which is unsupported
for serialization - but we need to serialize @_alwaysEmitIntoClient functions
so the client's code is able to see them.

This patch resolves the issue and adds proper handling of custom derivatives
of @_alwaysEmitIntoClient functions. Note that either both the function and
its custom derivative or none of them should have @_alwaysEmitIntoClient
attribute, mismatch in this attribute is not supported.

The following cases are handled (assume that in each case client's code uses
the derivative).

1. Both the function and its derivative are defined in a single file in
   one module.

2. Both the function and its derivative are defined in different files which
   are compiled to a single module.

3. The function is defined in one module, its derivative is defined in another
   module.

4. The function and the derivative are defined as members of a protocol
   extension in two separate modules - one for the function and one for the
   derivative. A struct conforming the protocol is defined in the third
   module.

5. The function and the derivative are defined as members of a struct
   extension in two separate modules - one for the function and one for the
   derivative.

The changes allow to define derivatives for methods of SIMD.

Fixes #54445

[kovdan01]

Tagging @asl

[kovdan01]

Tagging @JaapWijnen @rxwei

[asl]

@swift-ci please test

[asl]

@swift-ci please test

[asl]

@swift-ci please test

[asl]

@swift-ci please test

[kovdan01]

Would be glad to see feedback from everyone interested

[kovdan01]

Would be glad to see feedback from everyone interested

[kovdan01]

Would be glad to see feedback from everyone interested

[kovdan01]

Would be glad to see feedback from everyone interested

[kovdan01]

Would be glad to see feedback from everyone interested

[kovdan01]

Would be glad to see feedback from everyone interested

[asl]

@lorentey will you please take a look on stdlib changes?

[asl]

@jckarter Can you take a look into sil linker part? Thanks!

[kovdan01]

@lorentey Will you please take a look on stdlib changes?
@jckarter Can you take a look into sil linker part?
Thanks!

[asl]

@kovdan01 Will you please update the description? To summarize what is done, what is the issue, etc.

[kovdan01]

@kovdan01 Will you please update the description? To summarize what is done, what is the issue, etc.

Sure, I've updated the PR description.

[kovdan01]

@lorentey Will you please take a look on stdlib changes?
@jckarter Can you take a look into sil linker part?
Thanks!

[kovdan01]

@lorentey Will you please take a look on stdlib changes?
@jckarter Can you take a look into sil linker part?
Thanks!

[kovdan01]

@lorentey Will you please take a look on stdlib changes?
@jckarter Can you take a look into sil linker part?
Thanks!