Review how we deal with beta/provisional/experimental extensions

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

Start by reviewing the build-system USE_CL_EXPERIMENTAL option and searching the CTS sources and CI jobs for CL_EXPERIMENTAL and beta or provisional extension usage. Determine whether the current setup should be removed or replaced with explicit policies and coverage for builds with and without experimental extensions; the issue does not define a final approach.

Written by the indexing model from the issue text.