[META][AutoDiff] Fix autodiff for classes and class-valued arguments

[asl]

This is a meta-issue noting all kinds of issues related to differentiating of classes, class methods, etc. While the things are more or less working for ordinary functions and structs, there are lots of missed functionality related to classes.

• Classes-type function arguments have reference semantics. Therefore they should be treated semantically similar to inout arguments, however, there are lots of subtle differences. In particular, we need to fix activity analysis for classes, determination of semantic results, etc.
• There are lots of interesting special things around classes including e.g. accessors. Setters work by a chance (however, the activity analysis in anything involving setters is just plain wrong), and we do not support read / modify accessors.
• To support read / modify accessors we need to implement missed pieces of functionality around differentiation of co-routines. While semantically it is unclear how one could derive a derivative of function that essentially might return different values in general, we can narrow down task to support only @yield_once co-routines, where everything essentially returns only once, there is no way to resume / abort co-routine, so they act as a normal functions and @yield_once is just a way to transfer ownership.

Related issues:

• [SR-14116] Differentiation: class property modify accessor applications are not active #54685
• [SR-13096] Fix autodiff typing rules for class-typed function parameters #55542
• [SR-14115] SIL: derivative type calculation for coroutines #54404
• [AutoDiff] Refine pullback generation logic for reference-based types #67867

[asl]

Tagging @rxwei @dan-zheng @BradLarson

[dan-zheng]

Quick check: do we have non-toy motivating use cases for class differentiation? If yes, could we please share them here?

Features like class differentiation involve many design decisions, and it's nice to do use-case-driven development to ensure decisions are made in support of real use cases.

[asl]

This is for @BradLarson :)

[rxwei]

I second Dan's quick check. It seems that there are more important issues to tackle to bring us closer to Swift Evolution like ABI stability.