Native support for starting and waiting for ChildWorkflow

**Context and Goals**
Today we let user start "child workflow" from state execution, using `context.getChildWorkflowRequestId()` for requestId, and then using a signal/internal channel to wait for the childWorkflow to complete.

This pattern works okay, but this is a common pattern of using iWF that we can future improve on:
1. Write less code to start, and/or wait for the childWF to complete
2. Metrics: server should emit metrics(IQL) to know which child workflow is started by which parent
3. Linking: in Temporal WebUI, allow user to quickly find out the child workflowIds using Search Attribute(currently, it's only possible to find out the parent from children).

**Proposal**
ChildWorkflow can be naively supported with directly API/concepts in SDK.

We can have a new API in Client:
`client.startChildWorkflowFromStateExecution( context, workflowId, timeout, ... )` and handle that in api service so that server will know it's starting a childWF. context is required to have `context.getChildWorkflowRequestId()`.

We can also have a new command type:
`ChildWorkflowCompletionCommand.create(workflowId)` to wait for the childWF to complete.

* Metrics can be easily done as long as server knows there is a childWorkflow is started.
* Linking can be done by using a system search attribute like `IwfParentId`, and set the SA on childWFs when starting the childWFs. (Then we can find the childWFs using query like `IwfParentId="myParent123“`.

Start by reviewing the existing child-workflow flow through Client, state execution context, and the signal or internal-channel completion path. Define the scope for the proposed startChildWorkflowFromStateExecution API and ChildWorkflowCompletionCommand, including the metrics and IwfParentId linking goals; done means the proposal is implemented across the SDK and API service.

Written by the indexing model from the issue text.