Review how we deal with beta/provisional/experimental extensions

[kpet]

In https://github.com/KhronosGroup/OpenCL-Headers/pull/276 we started guarding the definitions for provisional extensions under an opt-in macro. We intend to use the same macro for other experimental extensions. The CTS has been assuming that all definitions are always available, provisional or otherwise. In order to not break CTS builds, beta extensions were always enabled as a first step with https://github.com/KhronosGroup/OpenCL-CTS/pull/2330.

We should review how we manage beta/provisiona/experimental extensions.

The build system has an USE_CL_EXPERIMENTAL option that we always turn on in CI jobs. This option, in turn, defines a CL_EXPERIMENTAL macro that is not AFAICT used in the code base.

I think we may want to either:

1. Remove USE_CL_EXPERIMENTAL and CL_EXPERIMENTAL and always build and test all extensions, beta or not.
2. Introduce clear infrastructure and policies for dealing with beta extensions. Probably something along the lines of:

• A build option that guards the inclusion of all tests that rely on beta extensions (on or off by default?)
• Coverage in the CI for both builds with and without the option turned on
• Think about how we would move extension tests out of under that build option