Move core away from OpenGL (JOGL) Dependencies

[!NOTE]
This issue is a Work In Progress about a long term goal.
It needs more discussion and is subject to changes.

Reasoning

There are a number of reasons to want to move away from OpenGL and JOGL:

• OpenGL is deprecated on macOS, and support could be removed at any time.
• JOGL is no longer actively maintained, raising concerns about stability, security, and the ability to adapt to new platforms.
• ...

Challenges

• Tight Coupling with Core Components: JOGL is deeply integrated with Swing, PGraphics, AWT, and Processing's event management system. This makes it difficult to migrate without breaking existing functionality.
• Rigidity of Modern Graphics APIs: Modern graphics APIs like Vulkan and WebGPU offer more control and performance but are more rigid in how the rendering pipeline is structured. Unlike OpenGL, which allows flexible, state-based changes at runtime, Vulkan and WebGPU require rendering pipelines to be defined upfront through fixed pipeline objects. This rigidity poses challenges for a creative coding tool like Processing, where sketches often rely on modifying drawing parameters on the fly.
• Backward Compatibility: Many sketches, libraries, and tools rely on JOGL-based renderers (P2D/P3D). Replacing them could introduce breaking changes. Small visual differences in rendering may also cause issues, especially in an educational context.
• ...

Research

• Look into OpenRNDR's approach: using Google’s Angle library. Emulates the entire OpenGL ES API. Bridges to Metal via MoltenVK, WebGPU via WGPU (Rust).
• LWJGL. There was an attempt by Andres Colubri and Jakub Valtar but it was abandonned. There is a working fork of processing where OpenGL was replaced with LWJGL by Neil C. Smith called libp5x.
• FX2D support for Processing exists via a library, but it has not been updated for years, and there are compatibility issues with recent versions of Processing. It may be a viable alternative to P2D.

Proposed Approach

• Modularize the Rendering Pipeline: Decoupling rendering from event management and UI layers would make it easier to support multiple backends in the future.
• Introduce a New Renderer Alongside JOGL: Instead of an immediate replacement, we propose developing and releasing a new renderer library (e.g., LWJGL-based) as an alternative to P2D/P3D. This would allow for gradual adoption, testing, and feedback without disrupting existing workflows.
• Phased Deprecation of JOGL: Long-term, we should consider sunsetting JOGL-based renderers once alternatives are stable and widely adopted. This would involve clear communication with the community, providing migration guides, and maintaining legacy support for a transition period.

Empieza por mapear cómo JOGL está acoplado a Swing, PGraphics, AWT y al sistema de gestión de eventos de Processing. Lee las referencias de OpenRNDR, LWJGL, libp5x y FX2D; después, define una ruta de renderizado modular que permita introducir un renderer alternativo junto a P2D/P3D sin romper los sketches existentes.