Log and drop signals whose params can't be deserialized (and other error handling improvements)

[cretz]

What was changed

• Log and drop signals whose parameters cannot be deserialized. This should not be a breaking change for anyone as the behavior before was to fail the task
• Support type hint helper properly ignoring self with new 3.11 typing.Self hint
• Start catching BaseException in activities. There should not be a reason (even a GeneratorExit or KeyboardInterrupt) where we wouldn't want to catch it

Checklist

1. Closes [Bug] Signals that can't be deserialized should be dropped/ignored #347
2. Closes [Bug] If self parameter is type hinted, it is not properly ignored when deserializing parameters #318
3. Closes [Bug] BaseException exceptions are not caught when raised in an activity #333

[Sushisource]

I see that the only things that could get raised from the call are decoding problems... but maybe it'd be a good protection to catch something a little more specific here, if that can be done w/o any incompatible change.

[cretz]

I think we want the change technically incompatible. This would fail the task before and I think the requirement is "any deserialization failure during signals causes log-and-drop". There is nothing more specific I can think of here. I guess I could skip Temporal failures, but I don't think we want to let any deserialization exceptions escape. If we do, I think I'd want to make it an option (failing the workflow from the signal arg converter is a bit rough, but may be wanted).