Add first_execution_run_id to missing requests and responses

[bergundy]

As discussed on slack, we need first_execution_run_id in all of these requests to make them safer.
Also added this to SignalWithStartWorkflowExecutionResponse to make using stubs / handles created this way safer.

[cretz]

LGTM. Would rather not merge this until we get the server impl at least POC'd to confirm no more changes/quirks are needed. Rollbacks and backwards-incompatible changes in this repo are a bit rough.

[bergundy]

We could probably add first_execution_request_id to GetWorkflowExecutionHistoryRequest too. It would be more efficient because we could start from the last run instead of iterating through all runs.

[yiminc]

I found this comment hard to read. Better to break it into 2 sentences. For example:
If set, this call will error if the target workflow is not part of the same execution chain as this id. Target workflow is specified by workflow_execution if run_id is set there, or the most recent run if run_id is not set on workflow_execution.

[macrogreg]

The PR only addresses a part of the "workflow chain overflow" scenario.
I think we need to hold off on merging it and instead address it holistically with the part of returning the "workflow chain IDs" back to the user.

See here for details: temporalio/temporal#2691

[bergundy]

Yes, I agree @macrogreg.
I didn't want to merge this before verifying the server can implement these API changes anyways.
Let's see if we can get this prioritized.

[bergundy]

We're not doing this anytime soon.