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.