Suggest replacing `.unwrap_or_else(|| panic!("..."))` with `.expect("...")` on `Option<T: Debug>`

What it does

Makes this roundabout way of writing .expect actually an expect call where it's feasible.

Advantage

The code is shorter and more straightforward in what it does, and IMHO more idiomatic.

Drawbacks

The parameter to expect is evaluated even when it doesn't end up being used.
Cf. unwrap_or vs. unwrap_or_else.
Not a big deal for literals, but could be significant in rare cases.

Example

This is a straight-up real-world example. I can trim it down upon request.

                full_output.platform_output.cursor_icon = player
                    .ui()
                    .downcast_ref::<DesktopUiBackend>()
                    .unwrap_or_else(|| panic!("UI Backend should be DesktopUiBackend")) // <--
                    .cursor();

(https://github.com/ruffle-rs/ruffle/blob/2621dd78eefab17e98dc03fafa25ed421784a712/desktop/src/gui/controller.rs#L213)

Could be written as:

                full_output.platform_output.cursor_icon = player
                    .ui()
                    .downcast_ref::<DesktopUiBackend>()
                    .expect!("UI Backend should be DesktopUiBackend") // <--
                    .cursor();

Start with the linked example in desktop/src/gui/controller.rs and compare the shown unwrap_or_else/panic form with the proposed expect call. Then locate the relevant Clippy lint entry point and tests; done means the lint handles feasible Option<T: Debug> cases and covers the transformation.