Reserved ^^ operator parsing ambiguity

OpenCL 3.0 (and earlier) reserves the `^^` token. However, OpenCL also works with (and encourages use of) the blocks extension, which uses `^` as part of its block expression syntax. This leads to an ambiguity with an immediately called block, as in:
```
unsigned x=0;
unsigned y=x^^{return 0;}();
```
This should result in `y` holding the value zero `(0^0)` through an immediately invoked block call as the right-hand side of the xor operator. However, it causes errors instead because of this reserved token: https://godbolt.org/z/navf7jTv1

Immediately called blocks (and lambdas) are not uncommon, so perhaps this is a reason to no longer reserve `^^` as a token. Another thing to consider is that WG21 is considering using `^^` as a token for reflection: https://isocpp.org/files/papers/P3381R0.html

Perhaps this token should no longer be reserved in OpenCL?

Start by reproducing the OpenCL C example in the linked Compiler Explorer and compare the reserved `^^` token with the blocks syntax. Read the issue’s references to OpenCL 3.0 and the WG21 reflection proposal, then determine whether the reservation should change. Done means the specification’s treatment of `^^` clearly resolves the immediately called block case.

Written by the indexing model from the issue text.