Feathers widgets cannot be ergonomically used in examples

## Motivation

Bevy examples should use GUI widgets where possible to demonstrate features and allow modification of behavior.

Right now, we use a mix of ad-hoc hard-coded keybindings with on-screen text for instructions, and fancy bespoke [example-only widgets](https://github.com/bevyengine/bevy/blob/main/examples/helpers/widgets.rs).

We've been developing a first-party UI framework for use within Bevy tooling: `feathers`! Examples are a prime example of where they should be used.

## Problem

`feathers` is not currently in Bevy's set of default features. There are two reasons for this:

1. Stability / polish (see #22934)
2. `feathers` are fundamentally dev tools and probably shouldn't be shipped in most end-user applications.

This causes complications for our hopes to use them in examples however. In order to use non-default features in examples, you need to specify required features for that example. https://github.com/rust-lang/cargo/issues/4663 means that the ergonomics for doing so are quite poor, significantly worsening the experience for almost all `bevy` examples as we move our controls over to `feathers`.

## Solutions

### Fix it upstream

Roll up our sleeves and do the social and technical work to actually fix https://github.com/rust-lang/cargo/issues/4663.

This is *mostly* outside of our control, and it's not clear that a compromise solution such as requiring prompting would be sufficiently comfortable.

### Work around the damage

Simply bypass `cargo`'s limitations around required features for examples and write our own wrapper that we tell users to always use when running examples.

This was done in https://github.com/TheBevyFlock/bevy_cli/issues/622. We would need to upstream and promote its use before swapping our examples over.

### `feathers` in the default features

Users shouldn't be shipping real apps with defaults features enabled. That's why we have feature collections! Instead, we've largely chosen to optimize our default set of features towards the new user experience, making the examples Just Work and allowing users to quickly mess around with toy projects.

We could enable `feathers` as part of the default features. If we choose to do this, we should do the same thing with our various camera controllers, and likely dev tools more broadly. A similar but milder version of this problem exists for the "free_camera" feature flag today.

This choice is *mostly* orthogonal to the "should we make feathers non-experimental" discussion. Concerns about broader usability and API instability are not really a concern for controls in examples. Only functionality and visual appeal are important.