Improve signalWithStart usability

[Spikhalskiy]

Workflow#signalWithStart method interface is overcomplicated and hard to use without checking with samples first.
We should improve the classes structure and provide more conventional builders and factory methods around this method and functionality.

[mfateev]

Such refactoring should keep the strongly typed way to call this method the current implementation provides.

[tsurdilo]

Wanted to suggest one possible improvement.
Currently with signalWithStart we can do for example:

WorkflowStub untyped = WorkflowStub.fromTyped(typedStub);
untyped.signalWithStart(...);

( or just create an untyped stub to start with ) so this works off just WorkflowStub (untyped)

WorkflowClient.signalWithStart only works off typed stubs, for example:

 BatchRequest request = client.newSignalWithStartRequest();
 request.add(myWorkflowStub::exec, input); // exec is workflow method
 request.add(myWorkflowStub::handleSignal, signalData); // handleSignal is a signal method
 client.signalWithStart(request);

It would be nice to add an "untyped" option for WorkflowClient.signalWithStart that takes in signalName, signalData, inputData.

Bonus question, whats the use for WorkflowClient.signalWithStart? When would you use it instead of WorkflowStub.signalWithStart?

[drewhoskins-temporal]

We've recently shipped updateWithStart in pre-release, and we hope it has better usability.
If it goes well, we'd like to make signalWithStart adopt this pattern for better usability and consistency, so please take a look.

[Quinn-With-Two-Ns]

Closing as a duplicate of #2213