Native support for starting and waiting for ChildWorkflow

[longquanzheng]

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“.