Test for orphan parent-child relations

[TheRawMeatball]

Currently, using Commands::despawn() leads to orphaned parent-child relations. These should be automatically cleaned up, so this PR adds a test case against such orphan relations.

[alice-i-cecile]

(Apologies to @cart if this functionality already exists and we somehow missed it buried somewhere.)

At a high-level this shares a lot of the same challenges as indexes (#1205): you have more than one delocalized copy of the data.

However, because entities and components can only be removed at sync points (between stages), our freshness concerns are much lower. We can carefully control mutation via a limited API, so our only concern here is how to make sure orphaned components are also removed.

Linear search solution

The naive solution here would be to add a system that runs at the end of each stage. Scan through every copy of Parent and every copy of Child, and assert that the entity they point to exists. Remove all orphaned components.

We can speed this up a little bit by keeping a list of the entities that have had their component removed, but this is still linear time.

This works, but has bad complexity due to wasted work.

Cached solution

I think we could use Removed<Parent> (and its counterpart) to get a list of entities that had the given component removed (including via deletion of the entire entity?), and then use a cached copy of the parent-child relation from just before the component was removed to find the corresponding pair.

This requires us to update a cached copy of the component every time it's changed though, which seems like it may be frustrating and slow.

Index solution

If we had a working index solution, we could use it to cull the orphan relations by grabbing the list of entities with Removed, and then looking them up in our index.

This requires #1205 to be resolved though.

Notes

1. I don't think we can use the Drop trait to ensure this work occurs, because it only gives access to &mut self.
2. It would be nice to have a reusable solution for these types of components: defining relationships between entities is common and useful, but ensuring API hygiene and working cleanup is a pain. I've been chewing on an idea for "relational components" to generalize this pattern in the manner of compound keys, but that's a discussion for another place.

[TheRawMeatball]

This problem will hopefully be solved eventually with the addition of relations (#1627), so this PR can be closed until then :)