Extend system piping with system calling

## What problem does this solve or what need does it fill?

When loading gltf scenes, many children are created with `Name` component (especially with animation). It is easy to add a tag component to the spawn of gltf scene, but not to children of that scene. Specifically with animation it can be useful to get the animation player whose parent's parent is tagged with some component. Or get a bone named "Hand" to child something being held to the hand's transform. In order to do that, currently we need to have a `Query<(&Children, &Name)>` and recursively iterate over all of the children and childrens of children to either find what we need or follow some path-hierarchy of the names.

To achieve this for multiple tags in multiple systems, the best approach is to have a helper function like

```
def find_child(children:&Query<(Entity, &Children, &Name), path:&str) -> Entity { ... }
```

and make sure to add such a query to the system and use this function.

## What solution would you like?

A better solution would be to have something like a `CallableSystem` struct as an argument where `find_child` must be a registered one-shot system. The typing logic will follow a very similar methodology for piped system - essentially all Queries are joined together to form a set of constraints for parallelization, however it'll allow us to create parametrized sub-systems that are potentially callable more than once per main system execution. It will also let users to declare call-sites as the system argument, rather than add_system modifier which will likely remove some unexpected bugs by bringing context closer to the implementation. This will also allow bevy hierarchy to have `find_child` as a pre-registered one shot systems that users can use out of the box.

Start by reviewing Bevy’s existing system piping and one-shot system registration, then trace how queries are joined for system constraints. Compare the proposed CallableSystem argument and hierarchy find_child use case with current system APIs; done means a decided, documented design and an implementation plan, since no files or tests are named.

Written by the indexing model from the issue text.