Improve handling of various non-serializable Exception situations

[AArnott]

There were a few issues:

1. We didn't gracefully handle exception types that were missing the [Serializable] attribute. Now we log a warning and just write out CommonErrorData.
2. We didn't gracefully handle exception types that were missing the deserializing constructor. Now we log a warning and deserialize the nearest base type that does conform to the serializable pattern.
3. We weren't even serializing thrown exceptions to JSON ourselves (newtonsoft.json was doing it) which means it wasn't treated as 'user data'. Now we serialize thrown exceptions with our own converter as user data.
4. Exceptions weren't serialized to include their assembly name, so unless the assembly was already loaded, we wouldn't be able to activate it. Now we artificially add AssemblyName as a property of the exception.
5. Even if exception's assembly were already loaded, unless it was loaded in the From load context it still wouldn't be found. That's still the case with this change, but if the assembly name is specified we'll load it into the From context automatically, assuming the CLR can find it.
6. Even if the assembly was loaded in the From context, if the assembly version of the transmitting side exceeded the assembly version on the receiving side, it wouldn't load properly. Now we fallback to allow an assembly version mismatch (provided the name and public key token still match). We further fallback to any (loaded) assembly that defines a type with a matching full name.

Fixes #588
See also DevDiv-1240018, #468