Rename many types to better reflect their usability (in the context of Components and Resources)

[Adamkob12]

Objective

• pick up the first half of Implement methods to list all components and all resources (Rebase of PR #3012) #4955 (refactor & rename of common types)

Solution

• Rename many types that had the word Component in the them to a name without the word Component (usually Data) to reflect that they could be used in the context of resources as well.

---

Changelog

• Rename Components to WorldData
• Rename ComponentId to DataId
• Rename ComponentDescriptor to DataDescriptor
• Rename ComponentInfo to DataInfo
• Rename some local variables in different methods to reflect these changes (use component_id, data_id and resource_id appropriately based on the context)
• Rename components field in World to world_data

Migration Guide

• Use WorldData instead of Components
• Use DataId instead of ComponentId
• Use DataDescriptor instead of ComponentDescriptor
• Use DataInfo instead of ComponentInfo

Additional Context

At first I wanted to f i x #3007 in one PR like #4955 tried but I realized that all of the refactoring and the renaming will make it very difficult to review. So I decided to split them out. This PR will be focused on renaming and iterating over all of the Components and Resources will be a different PR.

[joseph-gio]

I disagree with renaming Component to Data everywhere. It's more vague and doesn't communicate any specific meaning. Component meanings something specific within the ECS, and resources are just a special type of a component. It might be a bit counterintuitive at first, but that's okay because users never have to think about ComponentIds unless they want to. I'd rather have a distinct and meaningful name than a bunch of types named Data.

[Adamkob12]

I'm not too attached to either.
On one hand, using ComponentId and the like for resources is needlessly confusing (I remember I had had trouble with it)
One the other hand, it's actually somewhat informative regarding how Bevy handles resources.

I also worry that if another type would be added in the future (I vaguely remember hearing talk of Tag?) it would make it worse.

Another option is encapsulating Data stuff in a trait, and keep ComponentId(+) and maybe add ResourceId(+)
but that's probably too much.

[coreh]

I think Data sounds perhaps too generic, which might make it confusing? There's also the problem of pluralization, since data is already plural, so you can't pluralize it further.

What about:

• Rename Components to Representations
• Rename ComponentId to RepresentationId
• Rename ComponentDescriptor to RepresentationDescriptor
• Rename ComponentInfo to RepresentationInfo
• Rename components field in World to representations