Revert sending input as global state instead of parameter

[sfmskywalker]

This PR fixes a concurrency issue when sending concurrent workflow execution requests to the same workflow instance with different inputs.

Originally, this change was made to add support for sending large inputs from a parent workflow to a dispatched child workflow via a service bus.

However, that doesn't work when sending multiple messages concurrently, which we are seeing when using BulkDispatchWorkflow where multiple child workflows complete close to one another, overriding the "global" input state associated with the workflow input.

This PR attempts to only store the input with the workflow instance upon instance creation, while sending input alongside the dispatch message when resuming existing ones. The assumption here being that those messages include smaller input payloads.

The correct fix will be to revise the need for associating workflow input with the workflow instance, and instead provide mechanism to stash input externally from the workflow instance and instead passing in an identifier to that input.

[sfmskywalker]

@raymonddenhaan I considered it, but my last attempt to try and reproduce a race condition using a component test didn't pan out. Perhaps its possible, but I'd need a lot more time to try and achieve that. I am open to suggestions in case you have any.

[sfmskywalker]

Actually, I could try something similar to the WorkflowDefinitionActivityTests - it's a bit crude and doesn't guarantee the bug appears in case of a regression - but worked 99% of the times.

[raymonddenhaan]

Let's see if we can figure out how we can test these race conditions and if we can do it with 100% certainty without costing us a lot of time and resources in the build pipeline. This PR does not have to wait for that discussion.