[clang] [Clang][HIP][CUDA] Add `__cluster_dims__` and `__no_cluster__` attribute (PR #156686)

[Erich Keane via cfe-commits]

erichkeane wrote:

In response to https://github.com/llvm/llvm-project/pull/156686#discussion_r2350287123 (which it for some reason won't let me respond to):

```
Would a short description + a link to the appropriate section of the CUDA programming manual do? Brief description using established nomenclature is probably as far as we should go on the LLVM side, IMO, and we should leave the details to the CUDA programming guide, and PTX spec.
Including more (but not enough) details will not be of much help for the newbies.

The attribute name itself is distinct enough to make it easily googleable, or directly searchable for in the CUDA docs.
```

First, my understanding is that the Clang CUDA implementation is far enough from compatible with the NVIDIA CUDA thatthe CUDA programing manual isn't really all that great of documentation for us?  

As far as googleable/searchable in docs: I'm more worried about the OTHER direction.  A BIG part of the attributes documentation is 'attribute discovery'.  That is, someone reading through the list of attributes to FIND what they want.  So it needs to use sufficiently laymans terms to let the person decide "should I google this more?" or "does this not apply to my situation".

So a short-description + link WOULD be fine, but the 'established nomenclature' doesn't help the above particularly well.  I am not really looking for something particularly long, but just something that would help someone with no knowledge of CUDA, whether they should look at it more.

My problem with how it reads now: to someone with no CUDA knowledge, this reads as if a Markov model went haywire, and just uses a bunch of words that don't really mean anything (again, unless you already KNOW CUDA, at which point: why are you needing this doc?).  

So in the end: I want a paragraph or two description that explains what this does in laymans terms.  It can then link to the CUDA manual, but a 'high level' understanding should be attainable before we hit the docs.

<and before you say: yes, our documentation is pretty spotty as-is, and does a mediocre job of what I say.  Aaron and I have spent years trying to make the above happen, and have been lax at times in the past on reviews.  But this doc as-is is particularly egregious with this, so I'm looking for a bit of an attempt here>

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