Type refactoring and activity class/method support

[cretz]

What was changed

• Refactored to use callable protocols instead of callables where possible and moved into new temporalio.types package
• Support registering activity methods and calling them via start_activity_method, execute_activity_method, start_local_activity_method, and execute_local_activity_method
• Support registering activity classes and calling them via start_activity_class, execute_activity_class, start_local_activity_class, and execute_local_activity_class

Why?

Followup from #66 where we decided that instead of requiring fake instances each time you want to invoke an activity class/method, it's better to have first class support with overloads. We could not reasonably add overloads to the existing activity invocation functions without causing ambiguity that would give false negatives on bad types.

Checklist

1. Closes [Feature Request] Support non-function callables as activities #52
2. Closes [Feature Request] Inject dependencies into activities #68

[bergundy]

I didn't read all of the overloads, mostly went over the tests and those seem fine to me.

I wish we didn't have to have execute_activity_class but I trust that you researched this and it's impossible to avoid.

[cretz]

I trust that you researched this and it's impossible to avoid.

I minimally researched it but I expect callable-class activities and execute_activity_class to be very rare. It's only for classes with __call__ which, at that point, why wouldn't you use a method? I am tempted to remove it altogether.

Blowing up the execute_activity overloads any more just for this rare case does not seem worth it.