Fix typing of methods for pyright

[pvcnt]

What was changed

Since pyright 1.1.344, my code stated to fail with errors such as the following:

webapp.py:46:22 - error: No overloads for "execute_workflow" match the provided arguments (reportGeneralTypeIssues)
webapp.py:47:22 - error: Argument of type "(self: HelloWorkflow, name: str) -> Coroutine[Any, Any, str]" cannot be assigned to parameter "workflow" of type "str" in function "execute_workflow"
    "function" is incompatible with "str" (reportGeneralTypeIssues)

The code being something like:

@workflow.defn(name="HelloWorkflow")
class HelloWorkflow:
    @workflow.run
    async def run(self, name: str) -> str:
        return await workflow.execute_activity(
            hello_activity,
            HelloParams("Hello", name),
            start_to_close_timeout=timedelta(seconds=10),
        )

# and later in webapp.py:
return await env.temporal.execute_workflow(
    workflow=HelloWorkflow.run,
    arg="your name",
    id="workflow-id",
    task_queue="task-queue",
)

Despite looking legit, pyright did not like it. The issue is explained in microsoft/pyright#6875 and has to do with how the typing for methods is declared. I am attempting a fix here that I only tested with pyright for my use case, hoping that this will not break mypy.

Why?

To be able to use pyright with temporal.

Checklist

1. How was this tested:
   Only a typing change, relying on CI to fully verify it.

2. Any docs updates needed?
   No

[CLAassistant]

All committers have signed the CLA.

[cretz]

Thanks! This is passing our mypy CI checks (we have many calls that check the types there). I'll merge this now.

If you wanted to go further, you could add pyright as a CI step to ensure we don't break things like this in the future, but it'd also require doing whatever is necessary to make sure the SDK impl passes pyright instead of just the user-facing pieces. We'd totally support that effort of course, but understandable if you don't want to take that on.

[pvcnt]

Thank you for the prompt review! Yes, I suppose having pyright checks built-in would be ideal. If I find some bandwidth I might give it a stab, but I'm not sure yet.