Add BinaryFormatter auditing EventSource

[GrabYourPitchforks]

This is the last of the 5.0 runtime changes per the BinaryFormatter obsoletion document. This introduces a new EventSource used by the serialization infrastructure to tell you when calls to BinaryFormatter.Serialize or BinaryFormatter.Deserialize take place. The are currently 6 events raised in total:

• Serialization started (no args)
• Serialization ended (no args)
• Serialization of a non-primitive object is occurring (Type.AssemblyQualifiedName is provided as an arg)
• Deserialization started (no args)
• Deserialization ended (no args)
• Deserialization of a non-primitive object is occurring (Type.AssemblyQualifiedName is provided as an arg)

This feature is not a "global SerializationBinder" or a "global surrogate selector" and cannot be used to substitute types at runtime. Rather, as we begin to wind down BinaryFormatter within the runtime and libraries, it's meant to help app authors discover hidden BinaryFormatter dependencies within their own code or within any assemblies they pull into their apps.

There is an open question as to whether it would be useful to port this feature back to Full Framework as part of an overall defense-in-depth mechanism. I'm not considering that at the moment, but this code was designed such that it can be easily backported to Full Framework if needed. The code to hook up an EventListener would look the same both in Full Framework and in .NET 5.0+.

[GrabYourPitchforks]

@tarekgh@noahfalk You're on the review mainly as an FYI to make sure I haven't done anything bonkers with EventSource. :)

[noahfalk]

I spotted a few minor things you might want to address, overall looked good 👍

[noahfalk]

Nit: I typically suggest people not to worry about adding IsEnabled() checks unless you are on a very hot code-path trying to shave a few nanoseconds. The implementation within WriteEvent() will do an appropriate check.

[GrabYourPitchforks]

Followed up offline. Will leave them in for now since at least one of the operations (Type.get_AssemblyQualifiedName) guarded by the initial check might have side effects that we don't want to run if nobody is listening.

[GrabYourPitchforks]

@noahfalk@jkotas@tarekgh Thanks all for your feedback, both here and offline! I think the latest iteration addresses all of it. Please let me know if you have further suggestions. :)