Serialization context for converters and codecs

[cretz]

What was changed

• Added IWithSerializationContext<T> that can be implemented by data converters (and is), payload converters, encoding-specific payload converters, failure converters, and payload codecs to provide context-specific versions of themselves
• Added ISerializationContext as a base/marker interface for the contexts and nested Activity and Workflow class implementations of it
• Updated workflow client, schedule client, async activity client, workflow worker, activity worker, workflow outbound child, and workflow outbound external code to use context-specific converters/codecs.
• Added test to test most of those paths

Checklist

1. Closes [Feature Request] Serialization context for codecs and converters #438

[cretz]

When we added data conversion details to the existing HandleActivationAsync it complicated the code a lot because eviction was inside it too. So we took this opportunity to refactor and move eviction here to a separate method.

[Sushisource]

The royal "we" here is a bit hilarious lol

[cretz]

Maybe I have multiple personality disorder

[Sushisource]

Wow, definitely a bit of a laborious change.

I'm tempted to say it could maybe be a bit cleaner by creating some extension methods like asSerializationContext on things like some of the activation jobs/inputs/etc so that the places you're extracting info from them and turning them into a serialization context can be somewhat-deduped, and, maybe more importantly, just not create so much inline noise in the places where they're happening.

That's stylistic though and nonblocking

[Sushisource]

That was supposed to be approve

[cretz]

Yeah most of that inline noise is just .NET taking so many characters to type, not sure having single-use helpers will help too much. Yes this is a somewhat large effort, as it was in Java a couple years ago, and it's going to be really rough for whoever has to do this work in Python.