Slightly nicer handling of parent/child failure modes

[DJMcNab]

Objective

• Fix Panic on unwrap when calling despawn_recursive() #3195

Solution

• If a Parent's parent doesn't exist, despawn the entity containing it.

I think that for the case of scene spawning, we should probably have handling for when the parent of the scene doesn't exist and stop the spawning. However, this change also fixes that, with significantly less work required (as the SceneSpawner data structures are sub-optimal for adding that check).

Even with this fix, a 'general' case of this problem still remains. For example, if 'despawn' is called instead of despawn_recursive, we end up with a 'floating' entity. This entity would not have its GlobalTransform updated ever, amongst other issues. Detecting this is not cheap without a way to know the previous value of a removed Children component. (🎟️ ?) However, this version is still a better state of affairs.

In theory, we could have different behaviour here if the parent was despawned explicitly non-recursively. That is, one could argue that panicking in that case would be 'better'. However, we don't store that information, and cannot reasonably do so; taking the most 'optimistic' approach here is probably best.

[alice-i-cecile]

The limitations are unfortunate, but I think this is an improvement over the previous behavior.

Code also LGTM.

[DJMcNab]

This seems to be a 'duplicate' of #2410; that is, #2410 should also have fixed #3195.

However, #2410 doesn't fix @RobertoSnap's new issue, which occured problem because of this example:

bevy/examples/ecs/hierarchy.rs

Lines 42 to 61 in 44f370a

	// Another way to create a hierarchy is to add a Parent component to an entity,
	// which would be added automatically to parents with other methods.
	// Similarly, adding a Parent component will automatically add a Children component to the
	// parent.
	commands
	.spawn_bundle(SpriteBundle {
	transform: Transform {
	translation: Vec3::new(-250.0, 0.0, 0.0),
	scale: Vec3::splat(0.75),
	..Default::default()
	},
	texture: texture.clone(),
	sprite: Sprite {
	color: Color::RED,
	..Default::default()
	},
	..Default::default()
	})
	// Using the entity from the previous section as the parent:
	.insert(Parent(parent));

That should be fixed by this PR

[RobertoSnap]

Ran this PR with latest changes on local repo and local reproduction repo.

The Components got despawned as expected.

Here is reproduction repo which now runs successfully. UI gets despawned.

[cart]

Is this actually true? A parent no longer existing doesn't necessarily imply that the descendants should be despawned? Maybe the intent was to move the children to the top of the hierarchy?

[DJMcNab]

Like I say in the PR body, we cannot reasonably check whether despawn or despawn_recursive was called on the parent entity.

In my mind, a parent with all its children is an atomic unit, so it's much more likely that the user wants to despawn this child

But in general, this messiness is a consequence of how messy our entire parent/child system is; that is, I doubt this will be the final state. However, this patch makes the current state nicer, fixing an issue which several users ran into.

[DJMcNab]

This probably isn't relevant anymore