Rename `Bundle` to `Spawnable`

[alice-i-cecile]

As seen in #19613, bundle effects (#17521) have really pushed the limits of what our spawning API can do.

This is great, but the "bundle" terminology makes less and less sense. Originally, it meant a "bundle of components", intended to be inserted on a single entity. Now it means... something that can be spawned? But in some cases (like our querying API), it really is intended to solely mean a "bundle of components".

Interacts with #19491, which proposes changes to these traits.

[urben1680]

I have the impression that BundleEffect is just a disguised EntityCommand and it would be more clean to replace the first with the latter. This would unify the concept and even allows fallible bundle effects.

I wrote this in Discord yesterday:

1. replace BundleEffect with EntityCommand
2. simplify Bundle to components-only again
3. Make methods that allow bundle effect take a new trait BundleCommand<T>
4. impl BundleCommand<BundleMarker> for T: Bundle
5. impl BundleCommand<CommandMarker> for T: EntityCommand

Then SpawnRelatedBundle and SpawnOneRelated would just implement EntityCommand and it would be very easy to inject custom commands along bundles.

[andriyDev]

Just wanted to bring up that Spawnable could be confusing since you can also insert them on an existing entity.

I don't think that's more confusing though than Bundle today, so I'm all for it! Spawnable is a great name!

[alice-i-cecile]

I'm nervous about merging commands and BundleEffect: we need to think carefully about how that would interact with #10154. I do see your point though!

[janhohenheim]

Insertable?

[Atlas16A]

I'm against the name change.
Similar to the issue of event being shared between regular events and observer triggers, bundles is used for both "set of components to insert on entity" and "set and heiarchy of entities to spawn from a function"
While spawnable makes sense for the second case, it doesn't make as much sense for the first case. Bundles still are used in the first case, especially for required components that have no good default and require manual initialization.

[alice-i-cecile]

I agree that the trait is used too broadly: remove takes a Bundle, but I really don't think that it supports all of the fancy features that Spawn does for example.

Ideally we keep Bundle around for the simple "set of components" concept, and give a better trait name to the more powerful form.

[SkiFire13]

remove takes a Bundle

Note that after #19491 remove will take a StaticBundle, and Bundle will be used only for spawning and inserting

[cart]

I'm also against this name change. Bundle is not intended to be the "arbitrary templating pattern" and making it that would have negative consequences for the understand-ability and function of the system as a whole. See my comment here for rationale:
#19613 (comment)

[cart]

Closing this based on my comment here: #19613 (comment)

Bundles should continue to be what they are currently (a collection of a specific set of components). BundleEffect in combination with hierarchy spawning does slightly blur the lines, but not in a fundamental way. And any use of BundleEffect that does something else should be discouraged.