[clang] [coroutines] Introduce [[clang::coro_return_type]] and [[clang::coro_wrapper]] (PR #71945)

[Ilya Biryukov via cfe-commits]

================
@@ -11591,6 +11591,10 @@ def err_conflicting_aligned_options : Error <
 def err_coro_invalid_addr_of_label : Error<
   "the GNU address of label extension is not allowed in coroutines."
 >;
+def err_coroutine_return_type : Error<
----------------
ilya-biryukov wrote:

This makes sense, but I'm still not sure if it's better than having an on-by-default warning.
The use-case I imagine is adding `[[clang::coro_return_type]]` to an existing type. Currently, it requires fixing all (mis)uses of that type to compile the code and does not allow to have a two-step process (or at least makes it more complicated, e.g. one will have to hide the attribute under a macro).

If this was a warning, I can imagine some people marking the class with the attribute, rerunning the compiles to collect all places that need to be fixed via a warning without breaking the build and later grinding them as a separate step, while still preventing misuses in newly written code.

That being said, thinking more about the `std::function` angle of it, I think an error is a better trade-off, because there is no way to force this particular warning to be enabled in system headers (even `-Werror` won't help because it only applies if the warning wasn't previously filtered out).

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