Expose Required Component Info Through Reflection

Based on #14791

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

As the author of tooling for bevy (e.g. an editor frontend),
I want to be able to get the list of components that are required by a given component
so that I can show this to an end user nicely.

## What solution would you like?

We should expose an interface that for a given component allows getting (at least) the type paths of the required components.

## What alternative(s) have you considered?

- Telling people to just read the docs or look at the code.
- Expose another kind of data structure that is not per-component but maybe represents the entire graph in one go

## Implementation ideas

A reflection-based solution seems obvious, as that is what tooling will use to access the type data of a bevy world.

- We could add this to `ReflectComponent`.
- We could compute and expose this data on ComponentInfo. Recursive resolution might want to be done lazily.

### Alternatives

- Teaching `#[derive(Reflect)]` about the `#[require(T)]` attribute and addition of extra reflect data.
- Undesirable as it connects `bevy_ecs` and `bevy_reflect`. Right now, `bevy_reflect` is usable by itself.

Review the existing ReflectComponent and ComponentInfo APIs, along with the relationship between bevy_ecs and bevy_reflect. Compare the proposed per-component reflection data with the alternative graph approach and lazy recursive resolution. Done means tooling can obtain the type paths of components required by a given component without coupling bevy_reflect to bevy_ecs.

Written by the indexing model from the issue text.