Reconsider --enable-opencl / --disable-opencl

We no longer depend on OpenCL library nor headers being available on the system at build time (we load the library dynamically at runtime, and we use our own copy of the headers), but we still check for both in configure and don't enable OpenCL support if either or both are missing.

Do we want to continue checking (I think @claudioandre-br said so)? If so, or regardless, do we possibly want explicit --enable-opencl to override any checks (just like --disable-opencl would)? I've just tested, and it does not yet do that, and indeed we currently only document --disable-opencl. We'll also need to document --enable-opencl if we start supporting it.

As to the default, if we do continue checking, then maybe check only for the library? We definitely don't need the headers anymore, at all, but the library we'd use at runtime, so it makes more sense to check for it. Alternatively, we could make the check an OR - enable OpenCL support by default if at least one of the two - library or headers - is found at build time, indicating that the system is possibly meant to work with OpenCL and is maybe just slightly misconfigured.

Start by reading configure to trace the current OpenCL library and header checks, then find the documentation for --disable-opencl. Compare the existing behavior with the proposed enable/disable policies and determine which default and override semantics should be adopted. Done means the chosen configuration behavior is implemented and both options are documented.