Initial Render/Draw PoC

This pull request implements the port of our existing rendering pipeline for #954 as well as an initial port of the draw api for #955. The goal has been mostly fidelity to the original code, and while the draw API works, significant features provided by App and Frame are currently missing. I.e., you can issue draw commands but not much else.

General Description

At a high level, bevy_nannou_draw creates instances of Draw which exist in the main ECS game world. On every frame, that Draw is extracted by bevy_nannou_render into the render world and written into a ViewMesh component, which is eventually rendered by our NannouViewNode in the bevy render graph.

There's a bunch more fiddly details that I worked through here, but the goal was, in all places, to use the bevy equivalent, which means primarily we are using:

• Bevy's view and windowing system.
• Bevy's camera view projection for our shader.
• Bevy's "intermediate" texture which provides the "sketch" like behavior and is written to the swap chain for us.
• Bevy's depth texture and MSAA.
• Bevy's render graph, which means post-processing effects should (?) impact our sketch.

A general outline of the bevy systems that wire this together:

1. In the spawn_draw system, for each new Added<Camera>, we insert a Draw component on the Camera entity. This will allow later rendering code to tie a Draw to a specific view. A Camera can have a few different types of render targets, but mainly (and the only thing we support right now) this is a window. So without getting into more complicated multi-camera setups think camera = view = window.
2. In the renderer, we setup bind groups for our shader using bevy's view uniform, as well as any user supplied textures. The handling around textures is somewhat complicated right now, as bevy's asset system is fully asynchronous (see comment on Abstract the nannou::draw module into the new bevy_nannou_draw crate #955).
3. We extract Draw into the render world, where our main prepare_view_mesh system, which populates a ViewMesh component and list of render commands that are stored in ViewRenderCommands. Both of these are inserted as components on a ExtractedView, which is the render world equivalent of the Camera we inserted Draw on.
4. We run our NannouViewNode in the render graph at the end of the core 3d pass, which executes our nannou shader and writes to the texture provided by bevy. This means that: (a). we can draw on top of things rendered in the bevy pbr mesh pipeline and (b). we hook into stuff like MSAA for free.
5. Render ends and all of our components are dropped for the next frame.

How to review this pull request

Most of the files that have been copy/pasted from the existing code base into the bevy crates have been relatively lightly modified and should be mostly 1:1 copies and likely do not need super close review. I went back and forth whether these should just be modified in place to provide a better diff, but this would break the build on our branch and so I think the cost of ruining the diff history is worth it.

The primary changes were:

• Use bevy's wgpu wrappers
• Replace Rc<RefCell<T>> in draw with Arc<RwLock<T>>
• Replace Point2 with Vec2, etc
• Use bevy's Handle<Image> instead of wgpu::TextureView

TODO:

• Support user uploaded textures using the Bevy asset system.
• MSAA support.
• Confirm we can use bevy's dpeth texture.
• Figure out if text still works.
• Re-implement draw command analog to support switching textures, rendering multiple mesh, scissor, etc.
• Move ViewMesh to render world in prep for draw work.