feat: Add execute to createWorkflow context

[EvanBoyle]

Adds an execute method to the context provided by createWorkflow so that every component can evaluate subgraphs at the javascript layer.

This enables enables things like the fanout pattern and conditional execution in favor of the pattern we tried in #15

Here's the new example:

export const FanoutWorkflow = createWorkflow<
  FanoutWorkflowInputs,
  FanoutWorkflowOutputs
>(async (props, { resolve, execute }) => {
// this executes a subgraph at the JS layer
  const doubledNums = props.numbers.map(n =>
    execute(DoubleNumber, { input: n }),
  );

// execute another subgraph at the JS layer
  const doubledStrings = props.strings.map(s =>
    execute(DoubleString, { input: s }),
  );

// let operations run in parallel and resolve them. 
  const resolvedNums = await Promise.all(doubledNums);
  const resolvedStrings = await Promise.all(doubledStrings);

  return (
    <SumNumbers numbers={resolvedNums}>
      {sum => (
        <ConcatStrings strings={resolvedStrings}>
          {str => resolve({ num: sum, str })}
        </ConcatStrings>
      )}
    </SumNumbers>
  );
});

Notice that the execute API has an interesting signature:

execute(DoubleNumber, { input: n })

// execute(Component, props)

This is required in order to get type safety. I originally tried to do this via passing in JSX to execute, but unfortunately we lose all type safety.

execute doesn't currently support passing in children for a component. I'm not inclined to add support for it as it will add a lot of complexity (the return type of the thing becomes the return type of the last child, have to have patterns for chaining inputs/outputs together). But we can always add it later if we find a use case.

[EvanBoyle]

After some testing and getting internal and external feedback, we've decided that this approach has too many concepts and idiosyncrasies. We believe that the tradeoff to maintain type safety isn't worth it.

Plan is to ship the approach in #20 and follow up with experiments on typescript compiler extensions and LSP plugins to get the type safety we need until microsoft/TypeScript#21699 is fixed (if it ever gets fixed).