Improve BevyError ergonomics

[cookie1170]

Objective

Improve ergonomics when using BevyError

Solution

• Add .info(), .warn(), etc. shorthand methods for .with_severity to ResultSeverityExt
• Add a .context() extension method similar to the one from anyhow, which adds a "context" message to go along with the error. Also works on Option<T>!

Fixes #19714.

Testing

Added the context unit test to test messages produced by ContextError and a context_downcasting unit test to test that downcasting still works when using .context

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[Shatur]

Thank you for working on this! This should close #19714.

[SpecificProtagonist]

Generally in favor of both the severity shorthands and the error context, though they could be done in separate PRs because they're independent. The fix to backtrace filtering also shouldn't be part of this PR.

[SpecificProtagonist]

This seems odd to me and might be a bit confusing to use. Attaching a context to an option turns the context into an error? And options work with .with_context but not with .with_severity (as map_severity can't work with options)?

[cookie1170]

having an Option that's None usually means something failed, i.e. getting an element from an array, so you can attach a context message to it to turn it into an error that can be displayed. anyhow does the same thing so i just copied it from there really :p
having with_severity on an Option means that it'll need to turn into an error with some message, but if you then use context on it now you have 2 messages (i.e. some context message: option is none), which is different from if you first used context and then with_severity (you'll just get some context message)

[alice-i-cecile]

Generally in favor of both the severity shorthands and the error context, though they could be done in separate PRs because they're independent. The fix to backtrace filtering also shouldn't be part of this PR.

Agreed, I would prefer this split into three :)