Separate RenderGraphPlugin

[CptPotato]

Objective

As it stands, bevy_render is currently very monolithic.

It is impossible to "just" use bevy's mid-level rendering abstractions - i.e. the render graph, render world and corresponding scheduling (extract, prepare, etc.). Instead, the RenderPlugin pulls in a lot of high-level features such as transforms, hierarchy, cameras, views, visiblity, materials, meshes, mesh generation, colors and possibly more. To my knowledge there's currently no way to opt out of these.

Solution

Split the RenderPlugin into a separate plugin RenderGraphPlugin. This plugin is also used by the RenderPlugin to prevent code duplication.

---

Changelog

• Split the render graph into RenderGraphPlugin
• Make RenderPlugin depend on RenderGraphPlugin
• Add experimental example

---

Additional notes

I previously tried to separate the render graph into it's own crate. It worked but the diff was too noisy to review and there were a lot of unresolved questions (what abstractions should be part of each crate). Here are some random notes about things I've encountered for anyone interested. None of these are addressed in this PR.

notes

• Mesh support src/mesh/mesh and mesh generation src/mesh/shape
  • Mesh generation seems unrelated and can probably be separated
• Color features src/color seem unrelated to bevy_render
  • It looks like Wgpu::Color is enough for bevy_render internal use
• The use of Vec2 in src/texture seems out of place
  • It's used for image dimensions, but always converted from and to u32
  • As far as I can tell it's the only use of bevy_math in src/texture
• Confusing naming/structure of texture and image
  • Texture is in src/render_resource
  • src/texture contains Image and related formats
• Visibility bleeds into different parts of bevy_render
  • Extracting components has visibility specific behavior (ExtractComponentPlugin::only_extract_visible)
  • Visibility is part of src/view but seems unrelated (views should be able to exist without visibility)
• Windows, views and cameras seem tightly coupled
• Views require transforms

[alice-i-cecile]

I like this as a next step to splitting the rendering crates into abstractions that better match how they're used in practice.

[CptPotato]

I think at this point it doesn't make sense to keep this PR around.

I'd still love to see a leaner and meaner bevy_render or bevy_render_graph for custom rendering purposes, but this isn't it.