Add reset options to the ResetWorkflowExecution rpc

[award28]

READ BEFORE MERGING: All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted.

What changed?
Per temporalio/temporal#1338:

The ResetWorkflowExecution gRPC API accepts only workflow_task_finish_event_id. So all the logic of finding reset point resides in the tctl. This makes the logic not reusable when SDKs invoke reset operation directly.

Originally, I planned on addressing this by adding the reset_type described in that ticket and utilized in the CLI. However, after starting implementation, I found the batch operations already uses ResetOptions (see BatchOperationReset), which provides a more flexible and extensible solution.

If applied, this PR will add a reset_options field to ResetWorkflowExecutionRequest - This allows callers to specify reset targets (first/last workflow task, build ID, etc.) without needing to compute exact event IDs, bringing the same capabilities to single-workflow resets that batch operations already have.

Why?
This moves the reset point determination logic from the CLI into the service, enabling SDKs to perform user-friendly reset operations like "reset to the first workflow task" without implementing their own history traversal logic.

Breaking changes
Fully backwards compatible.

• The existing workflow_task_finish_event_id field remains unchanged and functional
• When reset_options is set, it takes precedence over workflow_task_finish_event_id
• Old clients continue to work without modification
• Follows the same pattern as BatchOperationReset, which has both options and deprecated legacy fields

Server PR
As I understand it, this does not break the Server. However, if reset options are supplied in the modified gRPC request, they will be ignored.

Next steps
Server-side implementation will need to handle the new reset_options field by:

1. Checking if reset_options is set and using it to determine the reset point
2. Falling back to workflow_task_finish_event_id if reset_options is not set
3. Implementing the target resolution logic
   a. I haven't confirmed this, but I'd imagine I could copy the logic from the batch operations.

[CLAassistant]

All committers have signed the CLA.