Initialize DiagnosticStore on register_diagnostic if it does not exist

[opstic]

Objective

• Fixes many_sprites and many_animated_sprites crashing on initialization #8782

Solution

• Call init_resource on register_diagnostic so that a DiagnosticStore gets initialized if it does not exist.

[nicopap]

This is a tricky behavior. Now, the user could forget to add the DiagnosticsPlugin without a panic.

So we have the choice between:

code	adds register_diagnostic before DiagnosticsPlugin	forgets to add DiagnosticsPlugin but yet uses register_diagnostic
main	panics	panics
#8819	runs	runs

bevy	Bug in user code?	Conscequences
panics	yes	user is annoyed, learn from panic message what the issue is and fixes it
runs	yes	user encounters a mysterious bug they have no idea how to fix, spend 2 hours fixing it
panics	no	user is annoyed, spend 2 hours trying to fix it, submits a bug to bevy when they figure out it originates from bevy
runs	no	user is happy 🎉

Honestly I think it's better to panic too much than not enough, so I think this should be solved differently.

Here is a suggestion: use get_reflect_mut over reflect_mut in line 307. Do

let Some(…) = …get_resource_mut…()  else {
   panic!("Add DiagnosticsPlugin _before_ calling register_diagnostic, or something");
};

[nicopap]

@mockersf what do you think? You suggested this change.

[mockersf]

This is a tricky behavior. Now, the user could forget to add the DiagnosticsPlugin without a panic.

Well... to be honest, I would suggest nuking the DiagnosticsPlugin completely. Its sole purpose is adding the resource (and also log system info), which is meaningless if you don't register a diagnostic. So the important part is registering a diagnostic, not adding the plugin which adds an empty resource, and it makes sense for me to move the focus from the plugin to the actual diagnostic.

That said, let's keep the plugin for now because it may make sense for diagnostics created during runtime.

I'm not sure how to read your tables, but registering a diagnostic before adding the DiagnosticPlugin, or even without adding it, will have zero impact / bug / anything. It will just work with this PR.

[nicopap]

I'm not sure how to read your tables

My concern was that the user would forget to add DiagnosticsPlugin, expect the behaviors from DiagnosticsPlugin and not see them and be surprised.

I didn't realize DiagnosticsPlugin doesn't add much behavior (so it's easy to know what is broken and how to fix it if you forgot to add DiagnosticsPlugin). In which case I think it's better to not fail if the user adds the diagnostics before the plugin.