CI: Fix vdb_view Windows build: include windows.h before GL/glu.h

[swahtz]

Problem

The windows CI job currently fails for every PR while compiling vdb_view, with ~100 parse errors in the Windows SDK's GL/glu.h:

glu.h(64,25): error C2146: syntax error: missing ';' before identifier 'gluErrorString'
glu.h(67,16): error C2371: 'APIENTRY': redefinition; different basic types
...
glu.h(277,6): error C1003: error count exceeds 100; stopping compilation
(compiling source file '../../../openvdb_cmd/vdb_view/RenderModules.cc')

These are the symptoms of GL/glu.h being parsed while the APIENTRY macro is undefined, so the compiler treats APIENTRY as an identifier.

Root cause

RenderModules.cc includes <GL/glu.h> on Windows and was implicitly relying on windows.h (which defines APIENTRY) arriving transitively through oneTBB's public headers, via the OpenVDB headers included earlier in the file. The windows-2022 runner image update at the end of June bumped its vcpkg snapshot from oneTBB 2022.3.0 to oneTBB 2023.0.0, which no longer includes windows.h in any public header — so APIENTRY is no longer defined when GL/glu.h is parsed.

GL/glew.h (included from RenderModules.h) cannot provide it either:

• glew.h only defines APIENTRY temporarily, undefining it again at the end of the header when it was the one that defined it, and
• vcpkg's glew package patches out glew.h's internal GL/glu.h include (its portfile rewrites ifndef GLEW_NO_GLU to #if 0), so glu.h is not consumed inside glew.h while APIENTRY is still defined.

Everything else was ruled out by diffing the last passing master run (June 18) against the failing runs: identical MSVC (14.44.35207), Windows SDK (10.0.26100.0), Boost 1.91, glew 2.3.1, glfw 3.4 and compile command — only the runner image and its bundled oneTBB version changed.

Fix

Include windows.h explicitly before GL/glu.h in RenderModules.cc instead of relying on a transitive include. Camera.cc, the only other GLU consumer on Windows, is unaffected because glfw3.h includes GL/glu.h while its own APIENTRY definition is still active.

This unblocks the windows job for all currently open PRs (e.g. #2219, #2241, #2244) once they rebase or re-run against master.

[kmuseth]

looks good to me