Add a Vulkan renderer backend to imgui-lwjgl3

[Enaium]

Summary

Adds a Vulkan renderer backend (ImGuiImplVulkan, port of imgui_impl_vulkan) to the imgui-lwjgl3 module, along with ImGuiImplVulkanH helper structures and createVulkanSurface() helpers for the GLFW and SDL3 backends. SPIR-V shaders ship as classpath resources. imgui-app gains a VULKAN backend (WindowVulkan) with swapchain, render pass, per-frame sync objects and resize handling, and the example module gets an ExampleVulkan smoke test.

Type of change

• Minor changes or tweaks (quality of life stuff)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Notes for reviewer

• This work is AI-assisted: the Vulkan backend port and the imgui-app integration were written with the help of DeepSeek. The commit carries a Co-authored-by: DeepSeek <noreply@deepseek.com> trailer.
• Multi-viewport is not supported (the binding has no Platform_CreateVkSurface callback yet); the sampler descriptor set is bound once in setupRenderState (no per-draw sampler switching).
• LWJGL's p* setters do not always set the matching *Count fields (VkPresentInfoKHR.pSwapchains in particular), so counts are set explicitly via native setters.
• GLFW_SCALE_FRAMEBUFFER is disabled on Wayland to avoid GLFW's viewport interfering with the Vulkan WSI.

Fixes #397

[Enaium]

[SpaiR]

After a quick glance, I can confidently say that the work generally looks solid. The limited scope, implementation within the app module, and working example are exactly what I haven't typically seen in previous implementations. I'll need a bit more time for a detailed review (as I'm simultaneously undertaking a major rewrite of the internal binding structure), but I don't anticipate your PR will be held up for long. At least from this initial look, I don't see anything that would be a blocker.

P.S. I want to specifically mention one thing. Given current trends, if any part of your work was done with the help of AI, please note it somewhere. Either as "co-authored" in the commit message, or if the commit is already pushed, simply add a line in the PR description. I have no bias against this whatsoever and actively use AI in my own work, but I just want transparency on the matter. If all the code was written manually, then all I can say is "impressive, very nice" 😅 In that case, there's no need to mention anything anywhere.

[Enaium]

Thank you for the quick look and the kind words! To address your note about AI usage: yes, this work was AI-assisted. The Vulkan backend port and the imgui-app integration were written with the help of DeepSeek, and the commit carries a Co-authored-by: DeepSeek <noreply@deepseek.com> trailer (see commit ad2ffaa). I've also added a note to the PR description for transparency.

Quick status for reference:

• Verified locally: ExampleVulkan runs on Linux (Wayland + X11) with ImGui content rendering correctly, including swapchain resize handling and the font atlas upload path.
• Shaders: the embedded SPIR-V arrays were extracted into classpath resources under imgui/vulkan/shaders/; custom shaders via InitInfo.customShaderVert/Frag are still supported.
• Known limitations (also in the PR body): multi-viewport is not wired up yet (the binding has no Platform_CreateVkSurface callback), and the sampler descriptor set is bound once per frame rather than per draw command.

[Enaium]

Tested on macOS