[clang] [clang] Fix GNU spellings of lifetimebound/lifetime_capture_by (PR #192070)

[Zeyi Xu via cfe-commits]

================
@@ -734,6 +734,13 @@ static void distributeTypeAttrsFromDeclarator(TypeProcessingState &state,
       continue;
 
     switch (attr.getKind()) {
----------------
zeyi2 wrote:

> the point here is that attributes that apply to the function type get attached to the function type. The fact that these AREN'T being distributed properly tells me that either this shouldn't be (which I don't think they should?) and thus adding them to the function type is wrong

The behaviour of `lifetimebound` seems a bit subtle here: https://godbolt.org/z/Wxvnx9n35

```
|-TypeAliasDecl <line:1:1, col:26> col:7 referenced F 'int () [[clang::lifetimebound]]':'int ()'
| `-AttributedType 'int () [[clang::lifetimebound]]' sugar
|   `-FunctionProtoType 'int ()' cdecl
|     `-BuiltinType 'int'
```

So I think it is fair to say that `lifetimebound` does have a real function-type-syntax. (for some cases)

But at the same time, I do not think we should put it in `FUNCTION_TYPE_ATTRS_CASELIST`, cases like this won't work:

https://godbolt.org/z/W4vG1WY7d

The diagnostic there is:

`error: 'clang::lifetimebound' attribute only applies to parameters and implicit object parameters`

So my current understanding is that the semantic subjects of `lifetimebound` are still parameters / the implicit object parameter, but Clang does use a function-type representation for at least some positions today. 

That's why I don't think it fits cleanly into `FUNCTION_TYPE_ATTRS_CASELIST` bucket, while the GNU postfix spelling still appears to need to reach the existing `TAL_DeclChunk` handling path.

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