Should feature macro be added in kernel language extensions

[AnastasiaStulova]

In OpenCL 3.0 feature macros were added but however, the extension spec has remained with the following statement:

A unique name string of the form "clkhr" is associated with each extension. If the extension is supported by an implementation, this string will be present in the implementation’s CL_PLATFORM_EXTENSIONS string or CL_DEVICE_EXTENSIONS string.

As a matter of fact, that doesn't regulate EXT and vendor extensions...

Some extensions start to appear with feature macros such as cl_ext_float_atomics while others stay with cl_ext_<name>.

Could we avoid different schemes for macros and just use one of the schemes?

[AnastasiaStulova]

Discussed in OpenCL Tooling call 21 Apr 2022:

• Preference to keep consistency in naming but also avoid adding macro duplicates for tooling scalability and maintenance reasons
• Perhaps feature style macros prefixed by __opencl_c should only be part of core spec functionality?