Static fixes

[Kerilk]

This addresses issue #269, as well as disable loader managed dispatch for static build, as it is fundamentally broken if several instance of the loader end up setting object dispatch data. To re-enable this we would need to get instance platform support (see here for prototype https://github.com/Kerilk/OpenCL-ICD-Loader/tree/cl_khr_icd-instance).

Note that we would need to expose a loader extension to allow deinitialization to be done explicitly on Windows in the static case, but this will need to be discussed. For now, the statically linked loader will be leaking memory on windows.

Unless @jenatali has a better suggestion.

[bashbaug]

LGTM.

We should probably add a couple of CI configs that build the static library if folks are shipping software using this path (#269 mentions FFmpeg).

[jenatali]

My suggestion would be to disallow static loader configurations on Windows. As we've discussed (at length), the OS is the piece that should decide how driver discovery works, and needs to be able to continue evolving and changing. Apps that get frozen in time that include driver discovery will be broken eventually. The CL ICD loader should not be facilitating this inevitable scenario.

[Kerilk]

My suggestion would be to disallow static loader configurations on Windows. As we've discussed (at length), the OS is the piece that should decide how driver discovery works, and needs to be able to continue evolving and changing. Apps that get frozen in time that include driver discovery will be broken eventually. The CL ICD loader should not be facilitating this inevitable scenario.

If I had it my way I would disallow static builds for all platform that support shared libraries. In practice, people will just hack around the restriction, so this tries to avoid some potential pitfalls around static library usage of the loader.