Actors uses different serializers for different purposes, not all of them are pluggable

## Expected Behavior

Actors uses a single serializer by default, and allows flexiblity for different choices for compatibility or user freedom.

The problem with not providing a consistent default is that different serializers have non-overlapping features sets, and different configuration settings. The choice of serializer usually ends up being tightly coupled with the users' data model through attributes and other extensibility.

For instance DataContract serializer requires types and properties to "opt-in" to serialization - System.Text.Json assumes that types and public properties should be serialized - and you should "opt-out" for anything you want to exclude. It takes **non-obvious work** to migrate between these models, and many users are not familiar with the nuances.

## Actual Behavior

Actors uses DataContract serializer (XML) for "remoting" method invocation (the choice of DCS is not configurable).

Actors uses System.Text.Json (JSON) for "non-remoting" method invocation (neither the choice of S.T.J nor the options passed to it are configurable).

Actors uses System.Text.Json (JSON) for state storage (the serializer and options have a replaceable abstraction).

Sidenote: Actors currently uses BinaryFormatter for exceptions in "remoting" method invocation, but that is planned for removal.

## Steps to Reproduce the Problem

Build an Actor system that uses "remoting". Try to share data models between the state store and the actor method invocation. You'll find that you need to annotate data models for *both* DataContract serializer and System.Text.Json.

## Release Note

We need to surface a design proposal and assess the impact of a change here. This is not a good users experience, but no simple change will fix it.