…engine#22757)

# Objective

- Test suite/demonstration for render recovery

## Solution

- Add an example that has ways to trigger various rendering errors

## Testing

- run it

Note: im opening this separately so that behavior on bevy main can be
compared to upcoming render recovery pr. It doesn't have to merge first
though.

# Objective

- Recover from rendering errors.
- Another step towards render recovery after #22714 #22759 and #16481 

## Solution

- Use `wgpu::Device::set_device_lost_callback` and
`wgpu::Device::on_uncaptured_error` to listen for errors.
- Add a state machine for the renderer
- Update it on error
- Add a `RenderErrorHandler` to let users specify behavior on error by
returning a specific `RenderErrorPolicy`
- This lets us for example ignore validation errors, delete responsible
entities, or reload the renderer if the device was lost.

## Testing

- #22757 with any of
```rs
    .insert_resource(bevy_render::error_handler::RenderErrorHandler(|_, _, _| {
        bevy_render::error_handler::RenderErrorPolicy::StopRendering
    }))
```
```rs
    .insert_resource(bevy_render::error_handler::RenderErrorHandler(|_, _, _| {
        bevy_render::error_handler::RenderErrorPolicy::Recover(default())
    }))
```

Note: no release note yet, as recovery does not exactly work well: this
PR gets us to the point of being able to care about it, but we currently
instantly crash on recover due to gpu resources not existing anymore. We
need to build more resilience before publicizing imo.

---------

Co-authored-by: Kristoffer Søholm <k.soeholm@gmail.com>