fix(linux): binaries fail to load with Mesa libGL (direct GL extension symbols); utvio FBO fails under llvmpipe

[mcoliver]

Summary

On Linux with Mesa's libGL (AMD/Intel GPUs, software rendering, the GitHub Ubuntu runners), UTV binaries that link the rendering libraries fail to load, and utvio can't render.

Found while wiring up ctest on Linux CI (#64).

1. OpenGL extension functions are linked directly

Linux builds define GL_GLEXT_PROTOTYPES and call extension entry points directly (e.g. glGenFencesNV, glBlitFramebufferEXT). libglvnd/Mesa's libGL.so doesn't export these symbols, so loading fails:

LoadingSharedLibrariesTest: symbol lookup error: ... undefined symbol: glGenFencesNV
ApplicationTest: symbol lookup error: ... undefined symbol: glBlitFramebufferEXT

• glGenFencesNV and friends are now looked up at runtime (test(ci): add CLI smoke and image format round-trip tests; run ctest in CI #64, eb145f3e). glBlitFramebufferEXT is next, and there are many more across IPCore/TwkGLF/RvCommon (roughly 840 direct GL calls).
• Windows already avoids this with GLEW (TWK_USE_GLEW, GLEW_STATIC). Proposed fix: enable the same GLEW loader on Linux (-DTWK_USE_GLEW, link GLEW, call glewInit() once each context is created), then drop GL_GLEXT_PROTOTYPES.
• Open question: does the main utv binary fail the same way on Mesa systems? The test binaries reference these symbols through statically linked RvApp/IPCore, so it probably does.

2. utvio offscreen render fails under Mesa llvmpipe

Under xvfb-run (24-bit screen), the GLX context is created and made current, but utvio aborts:

terminate called after throwing an instance of 'TwkExc::Exception'
  what():  ERROR: OpenGL: frame buffer incomplete: status = 0

glCheckFramebufferStatusEXT returning 0 means the call itself failed. Needs investigation, likely together with #1. Headless render nodes would benefit from an EGL/OSMesa surfaceless context as well (see #66).

CI handling until fixed

Linux ctest excludes LoadingSharedLibrariesTest, ApplicationTest, AudioRendererTest and image-format-roundtrip, and cli-smoke marks utvio as a known Linux failure (xfail). All other Linux tests are blocking. Remove the exclusions when this is fixed.

Operating System

Linux

Code of Conduct

• I agree to follow this project's Code of Conduct

[mcoliver]

Status: partially fixed by #64 (squash 999e8ba0).

Done:

• glGenFencesNV & co. resolved at runtime via glXGetProcAddressARB; stub fallback when GL_NV_fence is unavailable (TwkGLF/GLSyncObject.cpp)
• utvio reports a missing X display, missing GLX visual, or GLX context failure clearly instead of segfaulting (TwkGLFFBO/FBOVideoDevice.cpp)
• Linux CI runs tests under xvfb-run on a 24-bit screen

Remaining:

• Other GL extension entry points are still linked directly and fail to load on Mesa, e.g. glBlitFramebufferEXT. Proposed fix: enable the GLEW loader on Linux like Windows (TWK_USE_GLEW, glewInit() after each context is created), then drop GL_GLEXT_PROTOTYPES.
• utvio under Mesa llvmpipe aborts with frame buffer incomplete: status = 0 even with a valid, current GLX context. Investigate after the GLEW change.
• Verify whether the main utv binary starts on an AMD/Intel (Mesa) Linux desktop today
• Remove the Linux CI exclusions (LoadingSharedLibrariesTest, ApplicationTest, AudioRendererTest, image-format-roundtrip) and the utvio xfail in cli_smoke.py

Longer term, #70 (QRhi port) removes the direct GL dependency entirely.