Add fuzzy name matching tool for inspector

[alice-i-cecile]

Objective

When working with entity inspectors and similar tools (tracked in #23013), users want to enter strings and get a quick, approximate match.

We should PR this work separately for ease of review.

Solution

Provide the following APIs:

1. fuzzy_match_component_name: for looking up the metadata and summary statistics for component types
2. fuzzy_match_resource_name: same, but for resources.
3. fuzz_match_entity_label: look up entities by their entity label (Name, with fallbacks) per Add entity label resolution infrastructure for entity inspectors #25007.

Those should provide a solid foundation for lookups in interactive inspectors and editor tools (now that we finally have text input!).

There were a few meaningful design choices:

1. Each of these methods provide a Vec of results: this lines up with the standard tab-completion candidates UX.
2. There is a configurable cutoff for how good a match must be. We could do a "top N" instead, but that's easy to truncate as a caller and will be a bit slower.
3. I've chosen to go with Jaro-Winkler as our string similarity algorithm. My initial MVP of this in feathers_inspector used normalized Levenstein distance, but apparently Jaro-Winkler is a substantially better fit for this sort of autocomplete functionality, as it handles transpositions better and prioritizes the start of the words. Sorry friends who search for things by typing in the middle of the words :p I did not make this configurable because this is easy to write your own replacement for these random free functions.
4. The component/resource methods return a ComponentId and the entity label method returns an Entity. These serve as the primary keys into various inspector-flavored databases of this data, so were more appropriate than returning e.g. an EntityLabel.
5. I've opted for a strsim dependency over reimplementing Jaro-Winkler from scratch. If you really want we can vendor their battle-tested implementation but that mostly seems like dependency metric gaming vanity to me.
6. I decided not to include any logic for bulk-generating EntityLabels in this PR: that's fundamentally a front-end concern IMO in order to determine the filtering they want (e.g. no inspector entities, pagination). By contrast, the component / resource type searches should basically always just be globally so that's a &World function.

Testing

The underlying algorithms are tested extensively in strsim.

I can add more unit tests if y'all think it's appropriate but Bevy's logic here is pretty simple and should be stable, other than swapping out the distance metric if we want to.

[cookie1170]

why not use a dedicated fuzzy matching crate, such as fuzzy-matcher or nucleo-matcher? they're specifically meant for fuzzy finding, and have niceties such as getting the indices of the matched characters, which can then be highlighted to make it easier to see where the item matches what you're searching for, like shown here:

[alice-i-cecile]

I didn't realize such a thing existed! I'll swap over. Quick skim suggests that nucleo-matcher is the most mature.