[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> I can't imagine what optimizations that would enable.

It's more about correctness than optimization opportunities -- do we want to promise users that the behavior will always work in all circumstances on a bytewise copy? What about code like this:
```
va_list one, two;

va_start(one, something);
memcpy(&one, &two, sizeof(one));
va_end(one);

int i = va_arg(two, int);
va_end(two);
```
(The situation I'm specifically worried about is when the `__builtin_va_list` is storing pointers internally. e.g., https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/mpc5xxx/10564/1/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf
```
The type va_list shall be defined as follows:
typedef struct __va_list_tag {
unsigned char gpr;
unsigned char fpr;
/* Two bytes padding. */
char *overflow_arg_area;
char *reg_save_area;
} va_list[1];
```
it's possible that this works fine, but it's also possible that such an ABI would have different pointer values for different va_list objects within the same function.)

> I wouldn't want to lock us out of supporting a target that required a non-trivial va_copy for whatever awful reason, but we could be clear that it's only UB on such targets.

I'm not super happy about "this is well-defined if you happen to be on a target that makes it well-defined" because there's basically no reasonable way for a user to find that information out themselves. I think we need to provide explicit documentation for which targets are doing what if we're not using a blanket rule, but I don't feel comfortable making those assertions for the various ABIs on my own.

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