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

bevy_hierarchy is in an uncomfortable place: technically existing outside of bevy_ecs, but in practice generally privileged by the ecosystem.

One day (🥺), #3742 will replace bevy_hierarchy completely, allowing for generalized relations in a more robust fashion. This needs to be part of bevy_ecs, so bevy_hierarchy's days are numbered.

What solution would you like?

1. Move the core parent-child components and logic to bevy_ecs.
2. Feature flag this under an on-by-default hierarchy flag.
3. Move any transform propagation logic to bevy_transform.
4. Move any visibility propagation logic to bevy_render.

As follow-up, consider changing the default despawn behavior to act recursively.

What alternative(s) have you considered?

We could leave this alone, but this is causing problems when trying to tackle how #11090 interacts with hierarchies.

Additional context

Desired by @mockersf (maintainer), @maniwani (SME-ECS) and myself (SME-ECS and maintainer).