[clang] [clang] Introduce `SemaCoroutine` (PR #92645)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

> What is the goal here? there is a lot of code reuse in C++ and C. and having a file per feature is going to make thing worse (maintenance, unboarding, compile times).

Maintenance: one big blob of code which is `Sema` makes it virtually impossible to approach long-standing const-correctness issue in a systematic way, because enormous flat list of member functions doesn't help you identify the leaves of dependency chains to start there.

Onboarding: this effort started with an impression I had that it's almost impossible to wrap your head around `Sema` because of its size. This was an onboarding problem for me.

Compile times: per measurements taken in https://github.com/llvm/llvm-project/pull/84184#issuecomment-1984528598, indirection that splitting of `Sema` introduces doesn't have a noticeable impact on both our compile times and runtime performance.

> There are a lot more low-hamging fruits we should do before considering that sort of split.

> Wasm, AMD, Builtins, pragmas, random objects which could be in headers ( NestedNameSpecInfo, ContextRAII, NameClassification, AccessCheckingSFINAE, InstantiatingTemplate, SynthesizedFunctionScope, etc - I would recommend using Aliases so they are still functionally in Sema)

Time for that will come. Irrespective of the order we move stuff out of `Sema`, the hard parts (basically all the code for C++98 and, likely, C++11) will remain, because we haven't come with a plan for them yet. And those will be minor wins in terms of volume of code, because OpenMP miracle is unlikely to manifest again (when I was able to reduce `Sema.h` by almost 1k LoC).

C++ features not present in C++98 were identified as potential low-hanging fruits, because they are implemented on top of what was already there, and coroutines were indeed rather easy to factor out. C++20 modules are definitely not a low-hanging fruit, though.

https://github.com/llvm/llvm-project/pull/92645