Add bevy_post_processing

[IceSentry]

Objective

• Follow up to Add bevy_anti_aliasing #18323 and aligns with the points discussed in Restructure rendering crates #18423
• bevy_core_pipeline is still big and contains things that are not core pipelines. For example all the post processing effects.

Solution

• Add bevy_post_processing crate
• The only missing post processing effect is tonemapping because it's used in the core3d module. This could be resolved by doing what is mentioned in this issue Combine upscaling, rcas, and tonemapping passes into one "camera resolve" render node #16721

Testing

• Ran various post processing effects examples and things still worked

---

Showcase

main:

this PR:

Notes

This one is probably a bit more controversial than anti_aliasing because it's harder to move every post processing effect to this new crate. Also, the line between what is and isn't post processing isn't as clear. We might want to simply use a subfolder instead of a new crate.

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[JMS55]

This gets tricky.

Auto exposure shouldn't be here I don't think. DLSS is going to need to depend on it likely (haven't written that part yet). Which means that the anti aliasing crate would have to depend on the post processing crate.

Other potential issue, although I think you've handled this(?), is things like DOF and motion blur want to run before TAA/DLSS.

[IceSentry]

The main limitation is the render graph being limited in how and when you can add nodes more than the crate itself. Right now things work because the PostProcessingPlugin gets insert bevy the AntiAliasing plugin. But it will start to break when they depend on each other. I'm fine with waiting on a better render graph. But I had the code written already so I opened the PR since for 0.16 it would help a bit with compile time.

[robtfm]

i think this is worthwhile, even if other things end up depending on both crates it'll still be faster overall (since both compile faster than a single unit with everything in).

i haven't reviewed in detail since it's mostly copy paste. the node ordering looks the same and the examples seem fine.

approved pending ci obviously