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

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.

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).