Clean up duplicate type names and re-exports across `bevy`

[Atlas16A]

Bevy has reused the same conceptual names for multiple types across things within bevy. Ie Query is used by bevy_ecs and cosmic_text, Handle in Bevy_asset and bevy_log, etc
This creates confusion especially for autocomplete tooling like in vscode where the conflict leads to confusing errors that a normal person will not understand as syntactically they have done everything correctly.

Bevy should reserve the key conceptual ideas such as Query, Param, System, Handle, etc and any reuse should be name scoped, ex cosmic_text Query renamed to CosmicQuery etc

Checklist of conflicts:

• cosmic_text re-export: Remove re-exports of cosmic_text types #19516
• bevy_log re-export of Handle: TODO
• Entry: Rename bevy_ecs::world::Entry to ComponentEntry #19517
• bevy_assets::Entry: TODO
• bevy_scene::ron re-exports: TODO
• encase re-exports: TODO
• ScalingMode duplicate names

[hukasu]

#3823 (comment)

[Atlas16A]

I believe best route would be to go through and search common concepts. If a conflict is found favor the bevy local name, so ecs Query stays and rename cosmic_text Query to CosmicTextQuery or CosmicQuery. If a conflict is between bevy crates, such as Handle in asset vs log, we should favor the one thats more important to development, so Handle should stay in asset and in log renamed to LogHandle.

I think renaming with their scope like this is the simplest solution to it.

[alice-i-cecile]

Yep, I'd love a checklist in this issue of all of the items that need renaming. We should then tackle them one item at a time in separate PRs so they don't get stalled out.

[cart]

I think re-exporting cosmic text in its entirety should be reconsidered. Imo it should largely be an implementation detail, except for advanced use cases. People in that position can just add a top level dependency to their project.

[alice-i-cecile]

Agreed! That will also ease migration if we want to swap again.