Rethinking Font Propagation

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

Bevy 0.17 introduced the concept of "propagating text styles" which is currently only used in Feathers. However, the system as currently implemented has a number of weak points:

* It requires users to explicitly opt-in using the `ThemedText` component - this was a conservative choice because we weren't certain that people would like propagation by default.
* It breaks if there are intermediate non-text components in-between the widget and the text span.

Font propagation is important for two reasons:

* It's cumbersome for users who just want to create a text label to have to load a `Handle` from the asset server.
* Widgets such as buttons need to be able to dynamically change the color of their labels based on the widget state - this is hard to do because the widget doesn't control the label content.

## What solution would you like?

This was discussed on Discord in ui-dev, and a number of ideas were proposed. The favored solution was a combination of #20974 and opt-out inheritance:

* The existing font style components - TextFont and such - would now be optional
* A new component `ComputedTextStyle` would be computed, for each `Text` span, from either the current entity or the nearest styled ancestor.

This provides a very natural way for the users to style text:

* If the user does nothing (inserts no special components), then the text gets the default inherited styles.
* If the user overrides the style, that entity and any of its children get the overridden style.

## What alternative(s) have you considered?

The options considered were:

* What we had before: no inheritance, users are responsible for setting the font handle on each text span
* Opt-in font/text style inheritance
* Same but opt-out
* Font aliases: specify the font style via a static id
* Aliases for both font style and text style, like a CSS class name
* Some combination of the above
* Something I didn't think of

## Additional context

CSS provides automatic inheritance for font-related properties, but not for other kinds of style properties (this is different than the CSS cascade).

@ickshonpe @alice-i-cecile

Start by reading the current propagation implementation around ThemedText and the existing TextFont-style components, then review the proposed relationship to #20974. Determine how computed styles should be derived for each Text span and how opt-out inheritance should work. Done means the design is agreed and the relevant propagation behavior is covered by the project’s tests.

Written by the indexing model from the issue text.