Prevent clashing with user identifiers in extensions and future kernel language versions

In OpenCL C new identifiers are being added through extensions and new language versions even if they have not been reserved, an example is `sub_group_*` functions in OpenCL 3.0. While the clashes are unlikely this still leaves concerns from the developers regarding the actual backward compatibility of the new standards.

Technically if an old kernel source is not guaranteed to be compiled by the conformant compiler for a new OpenCL standard we can't claim backward compatibility.

I was wondering if the `cl_ ` prefix was supposed to be used for that purpose but it hasn't been used consistently. Many vendor extensions solved the issue by adding a vendor prefix to the identifiers e.g. `arm_`, `intel`, etc.

Should something be done for the future common extensions or even standard?

The issue names no files or tests. Begin by reviewing the OpenCL C rules for identifiers introduced by extensions and language versions, including sub_group_* and vendor-prefixed identifiers, then determine the scope of any compatibility policy. Done means the future naming or reservation approach is agreed and documented clearly enough to guide later standards work.

Written by the indexing model from the issue text.