Rework postprocessor handling in GLMakie

[ffreyer]

Description

This pr aims to rework and streamline postprocesser handling. I would like to implement a system similar to Nodes in Blender or Unreal Blueprints to handle the render pipeline. I.e. describe the various operations in render_frame() (z sorting, rendering plots, running postprocessors) as Nodes with connectable inputs and outputs. These nodes and edges should be free of OpenGL, i.e. an abstraction of what the backend is doing. Resolving them should produce a set of necessary buffers for data transfer and a pipeline of backend tasks to run in render_frame.

TODO/Plans/Changes:

• extract OpenGL parts of GLFramebuffer and move them to GLAbstraction
• rework PostProcessor type to better represent a renderloop task (generic abstract type with specialized implementations, try using dispatched function)
• add task for rendering
• add task for z sorting
• maybe add task for setup!()
• switch to one GLFramebuffer per task (as needed) instead of one global framebuffer
• if needed, implement GLFence for synching between framebuffers
• add a FramebufferFactory which holds onto all attachments, adds new ones as required and distributes them to postprocessors
• create and connect abstract RenderPipeline prototype
• Makie render pipeline: add optional requirements to BufferFormat (e.g. clamping, filter, mipmap, multisample?)
• Makie render pipeline: cleanup is_compatible_with() (only used symmetrical variant)
• cleanup old GLAbstraction.Framebuffer
• derive fragment_output from gl-render pipeline (i.e. base shader outputs off the relevant framebuffer)
• reconsider/cleanup:
  • frame setup!()
  • fxaa/ssao render stage
  • handling of colorbuffer, depthbuffer, picking (i.e. hardcoded names?)
• more directly integrate Makie Renderpipeline with Screen()
• improve usability of Makie render pipeline

Note: I started with this on #4150 and figured these changes can be done independently and are probably also useful independently. There is still some code related to that pr in here (e.g. glscene mentions) and I will probably make some decisions with that pr in mind.
Note 2: I'm mainly creating a pr for this now to get a benchmark and test history going.

Type of change

Delete options that do not apply:

• 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)

... or maybe just internal rework for now?

Checklist

• Added an entry in CHANGELOG.md (for new features and breaking changes)
• Added or changed relevant sections in the documentation
• Added unit tests for new algorithms, conversion methods, etc.
• Added reference image tests for new plotting functions, recipes, visual options, etc.

[MakieBot]

Benchmark Results

SHA: 84872f2cc5588a2ac62b41052cc18c9fe4795743

Warning

These results are subject to substantial noise because GitHub's CI runs on shared machines that are not ideally suited for benchmarking.