Add a way to automatically infer Error Severity based on error contents

[alice-i-cecile]

What problem does this solve or what need does it fill?

Suppose I'm making an error type, with many different error arms. Some of these problems are very bad, and some of them are "basically fine". I want to encode this information into the type, so my users have good default behavior when they lazily ? the results away.

Possible designs

Manual handling by users

You can always just call .with_severity when the error is generated. That's a lot easier to screw up though, and requires a lot of replication and deep knowledge of the internals.

This is the status quo.

Trait-based

Define a trait for InferErrorSeverity or the like (maybe FallbackErrorSeverity?). If an error severity is not manually provided, this trait will be used by the default error handler to infer the severity.

I'm not totally sure how that last bit would work! The lack of specialization is probably going to make this suck a lot.

We might need to increase the strictness of the From blanket impl, and then implement this for a ton of common error types, both inside and outside of Bevy. Bah!

Reflection-style function pointers

We could consider storing an error registry, and then storing the function pointers for this severity inference in there somehow? And then register all of Bevy's error types, with instructions for users to register their own. The reflect auto-registration machinery could work well here, but we definitely shouldn't pull in reflection itself.

Plugin-powered error registry

Another idea would be to store the fallback error severity inside of the handler itself, and expose an API for Bevy plugins to extend it by registering function pointers that take an error value by reference and return a severity. This pushes us away from a "replace the error handler completely" design, but ultimately I think that as long as you can overwrite the rules selectively this should work well.

This is particularly nice, because unlike the trait approach, it's completely non-breaking, easily dynamically inspectable and user-configurable.

Additional context

This would be a very nice way to make things like "despawned a despawned entity" still provide low-severity warnings, without crashing or being silently ignored.

We should not change the severity of any of Bevy's error types in the initial PR.