remove the OpenCL extension specification

[bashbaug]

fixes #437
fixes #1111

Moves the remaining content in the OpenCL extension specification into the main OpenCL API specification and the OpenCL C specification and removes the standalone OpenCL extension specification from the spec toolchain. Also updates the OpenCL reference pages and removes remaining links to the OpenCL extension specification.

Specifically:

• Moves the description of clGetExtensionFunctionAddressForPlatform and the older clGetExtensionFunctionAddress into the OpenCL API specification, as a sub-section of The OpenCL Platform Layer.
• Moves the extension naming conventions and header file conventions into the OpenCL API specification, as a sub-section of the existing OpenCL Extensions appendix.
• Moves the information about extension defines and pragmas into the OpenCL C specification, as a sub-section of the existing Preprocessor Directives and Macros section.

[bashbaug]

@oddhack would you mind giving these changes a quick review? We're aiming to merge in the OpenCL teleconference next week, on January 27th. Thanks!

[oddhack]

Maybe add a note that exts not approved by the WG are still found separately?

[bashbaug]

Good idea, I added a note to the section about vendor extension conventions:

Vendor extensions are not currently included in the OpenCL specifications, but vendor extension specifications are frequently included in the online Registry of extensions.

[oddhack]

Are you not generating vendor extension interfaces for the headers? I thought all that stuff was in the XML already but haven't looked in quite a while.

[bashbaug]

We are, but it doesn't look like we include any information about the XML file in the spec, currently.

I'm open to adding this, but I would prefer to do so in a separate PR.

[oddhack]

For reference, for Vulkan we consider the XML to be a normative part of the spec (hard not to, since a substantial amount of the spec is generated from the XML), but the exact XML schema / toolchain are documented separately in the RNC schema and in a separate https://registry.khronos.org/vulkan/specs/latest/registry.html human-readable description of the schema. So in the spec we just point to the registry.html and mention the XML occasionally as a source of truth, but little more.

[oddhack]

Could this be integrated in a refpage block in the API spec, along with the extensions?

[bashbaug]

Good idea, done! Since the page is auto-generated now, I've removed the static page.

[oddhack]

LGTM. Minor suggestions for folding in additional stuff to the API spec.

[bashbaug]

I think all of the review comments have been addressed, so I am going to go ahead and merge this. We can always make additional changes later. Thanks!