Change most RenderApp accesses to panics instead of silently doing nothing/half the work.

[andriyDev]

Objective

• Pretty much all rendering stuff right now will do nothing if added before the RenderPlugin.
• Some of these cases also use if let Some(render_app) which adds a whole extra level of nesting.

Solution

• Make them panic if there is no RenderApp! It is better to give a more immediate warning than your app just silently doing nothing. This also reduces nesting in some cases.

• One case is special (in crates/bevy_render/src/lib.rs): the RenderPlugin itself calls initialize_render_app, and then later checks if we have the RenderApp. By moving this if to the initialize_render_app function, we avoid the useless branch and the problem goes away!

• There are 4 remaining cases that I did not handle. I am willing to fix all in this PR if that's desired.

  • bevy_text adds an extraction schedule for extracting the text2d sprite to the rendering stuff. In theory though, a user could be using the bevy_text stack with their own rendering (so reusing the layout and stuff). This one I am the least confident about. I added a comment explaining this one.
  • bevy_gizmos prints a warning message about having the plugins in the wrong order. Since this is also messing with feature flags, I didn't feel compelled to mess with it.
  • bevy_render ExtractResourcePlugin prints a warning message about having the plugins in the wrong order. Since this plugin is intended to be added by users, and we already have a message, I decided to leave this alone.
  • bevy_sprite::SpritePlugin may be added even in headless situations (e.g., to register the Sprite type for spawning scenes). I added a comment explaining this one too.

---

I don't think this needs a migration guide, since no one should be depending on this - the plugins would pretty much do nothing before anyway.

[andriyDev]

This PR is already paying itself off! Previously ExtractInstancesPlugin<EnvironmentMapIds> was doing literally nothing, since it was being added to the RenderApp subapp, but internally it would look for the RenderApp subapp. This means it would always find None and never do anything. The panic made it clear (and unavoidable) to fix this.

I have no idea what this plugin does, but it seems reasonable to say it shouldn't be doing nothing (and if it is, we should just remove it outright).

[alice-i-cecile]

My kingdom for real plugin dependencies :( #1255 please.

[andriyDev]

This PR might not actually be the way. It turns out if you have no rendering backends we don't insert the RenderApp at all (when using an automatic render creation). So if you disable all the backends explicitly every plugin is gonna start panicking. One user on discord did mention explicitly disabling all render backends so they could use their own rendering (while still getting access to all the main world component stuff from the render plugins).

I'm not really sure what to do here, @alice-i-cecile. Even in a world with plugin dependencies, we'd still need to do this conditional check. That doesn't seem desirable and almost seems like we shouldn't support having no backends, but I don't know what the implications of that are.

[janhohenheim]

Could we use error! instead of panic!? I know it shouldn't matter, but in case someone's project has weird orderings that are useless, it's very annoying to upgrade your project and find out that it crashes due to some bevy_rendering stuff that you maybe didn't even setup yourself, but imported through a dependency. Though that seems unlikely in this case, admittedly.

But I can imagine someone's CI setup depending on a missing RenderApp being ignored, for example.

See also point 3 of #12660:

[IQuick143]

+1 on error! instead of panic!