Rename `Parent` to `ChildOf` and `Children` to `ParentOf`

[alice-i-cecile]

When I started learning how to use Bevy recently, this was the first stumbling block. It seemed straightforward that Parent was a marker component (or "driving concept") for a parent entity!

Originally posted by @physgun in #17398 (comment)

[alice-i-cecile]

This is the IsA vs HasA terminology debate, to borrow some terms from flecs.

[alice-i-cecile]

When doing this, we should be sure to keep the old names around as deprecated type aliases for a cycle.

[viridia]

I proposed in #17398 (comment) that each relationship actually have three names:

• The component in the 'from' entity (the one in the one-to-many relationship), e.g. ParentOf (formerly Children).
• The component in the 'to' entity, e.g. ChildOf (formerly Parent).
• The name of the builder / constructor used to spawn a new entity that is related to the current entity.

So for example, something like:

Relation type	From Component	To Component	Constructor
children	ParentOf	ChildOf	Children
observer	ObservedBy	ObserverOf	Observers
ownership	OwnerOf	OwnedBy	(none, construction is always implicit)

I didn't specify names for reactions because IMHO reactions don't need a special relation type: ownership is sufficient.

[cart]

I would prefer it if we didn't need to build special-cased constructors for these things:

1. I don't love having two names for the same concept.
2. I'd like these APIs to be relationship-type-driven, especially given that Relationships are a "generic user-facing system". Ideally they define both sides of the relationship and can immediately start spawning things in the same way Bevy's built-in relationships do it.

Ex: If ParentOf is the component name, then it should also be the thing that we use during spawn. ParentOf is actually reasonable in this context:

world.spawn((
    Foo,
    ParentOf::spawn((
        Spawn(Bar),
        Spawn(Baz),
    )),
))

world.spawn((
    Foo,
    parent_of![
        Bar,
        Baz,
    ]
));

bsn! {(
    Foo,
    ParentOf [
        Bar,
        Baz,
    ]
)}

(note that my current plan for BSN and ParentOf is to make [ ] imply ParentOf [])

If we do want to refer to the "collection of childof relationships" as "children" in this context, then we should violate our "IsA" constraint and just give it the name that makes us happy. Needing to connect ParentOf to a new "children" concept name is confusing and needlessly complicated. I don't think losing IsA here is a particular loss. It wouldn't be the first or the last case where "IsA" naming doesn't quite fit (as mentioned above).