Add init method to workflow

[Spikhalskiy]

We should add an init method to workflows that allow some code to be run before any query, signal, or workflow method is processed.
This method should have access to workflow method input parameters.
This method doesn't have the same properties and guarantees as a workflow method. It shouldn't omit commands and doesn't work with WFT, because it would make it indistinguishable from the workflow method. It should be just a regular Java method.

This should solve the following situation:

1. A signal method can arrive before the workflow main method execution (reset preserving the signals on the first workflow task)
2. A signal method may require some initialization to be done.
3. General advice is to perform the initialization in the constructor or init block, BUT some initialization may require access to workflow input parameters. In this situation, users have to perform non-trivial gymnastics saving the signals in the field and processing them in a delayed manner in the workflow code.

It will also make it extra clear that Signals may arrive before the workflow code in triggered and the initialization should be handled with caution in some cases.

An alternative is to make the constructor such an init method. It will play nicely because it will be clear that it's not a workflow code and doesn't have properties of the workflow code.

Dynamic Workflow

With regular typed workflows, listeners (signals and queries) are registered by SDK before processing signals. Currently, it's impossible to mimic this behavior with Dynamic Workflows.
Right now the only way to register listeners in Dynamic Workflow is to call the register methods from the workflow code.
But with signalToStart, signal is getting delivered before the execution of the workflow method, at the moment when Dynamic Workflow code didn't execute yet, hence no listener is present.
This makes init() method a necessity for Dynamic Workflows, not a convenience.

Related to #864
Related to a discussion under a user request in a community slack: https://temporalio.slack.com/archives/CTT84KXK9/p1636375128042600

[cretz]

Saw #2166 was marked as dupe.

I do want to make sure there is a clear difference between "run any code before start/signal/update" and "initialize state before start/signal/update". I think @WorkflowInit can be a constructor annotation that, when set, means the constructor accepts the exact params as the primary workflow method (enforced at registration). Users can use this to set final fields that rely on start parameters. But I don't think we'd want to encourage command-creating logic in the constructor (though I guess it's technically possible in Java where you don't have to mark it async). I think general initialization code that creates commands is a different topic.

[Quinn-With-Two-Ns]

I think general initialization code that creates commands is a different topic.

I agree, but that is not covered by the feature request