Refactor the PixelPaint filter pipeline for performance and modularity

[kleinesfilmroellchen]

While working on #14840, I noticed several problems with the current PixelPaint filter pipeline:

• Some filters are implemented in PixelPaint, some in LibGfx. Some appear to be implemented in LibGfx (like the Gaussian blur filters), but those classes don't actually hold kernel parameters.
• The apply API receives C++ references to bitmaps, making it impossible to use cheap moves for temporary bitmaps.
• The apply API's source and target bitmap are almost always aliased (which C++ allows, which is a language flaw we need to work around here), meaning that a copy (which cannot be moved as discussed above) is always necessary.
• All apply calls happen on the GUI thread, causing hangs for compute-heavy filters.

This causes performance problems and necessitates unclean workarounds. I therefore suggest the following rearchitecting, which can for the most part happen in small modular steps:

• [ ] Make PixelPaint::Filter::apply() non-virtual to enforce correct and uniform handling of source and target bitmaps as well as the edit stack.
• [ ] Change the virtual apply API that filters implement to apply(NonnullRefPtr<Bitmap>, NonnullRefPtr<Bitmap const>) and never call it with aliased smart pointers; i.e. users can overwrite the target however they like and assume it starts out with the same size and format as the source.
• [ ] Move filters into LibGfx wherever possible.
• [ ] Actually implement the pseudo-filters like the Gaussian blur in LibGfx (the code is already there, just in PixelPaint, mostly FilterParameters).
• [ ] Implement a PixelPaint::Filters::LibGfxFilter templated mixin class that delegates to a LibGfx filter and handles 90% of simple filters.
• [ ] Rearchitect filter previews and application to happen on another thread
• [ ] Provide a way for the filters to report progress.
• [ ] Allow the GUI to interrupt filter application (which is quite easy with threads and/or flags).
• [ ] Do not render a preview if the user chooses so or the filter takes too long to compute.

CC @TobyAsE I want to hear what's your opinion on this.

[TobyAsE]

The filter architecture gave me a headache since I updated it for the Gallery. I love seeing the suggestions on this! I'm not too sure whether moving all the filters over to LibGfx is possible, let's see where this goes when we come to it.

Great having people care about PP :^)